15 mai 2010

ITIL V3 : Glossaire intégral des termes, définitions et acronymes

Filed under: ITIL — urbandot @ 21 09 28 05285

Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

ITIL V3 : Glossaire des termes, définitions et acronymes -
actualisé le 07/05/2010.

Terme anglais	Terme français Retenu	Définition
Acceptance	Acceptation	Accord formel sur le fait qu’un service, processus, plan des TI, ou autre livrable est achevé, précis, fiable et satisfait aux exigences spécifiées. L’acceptation est habituellement précédée d’une évaluation ou d’un test, elle est souvent nécessaire avant de passer à l’étape suivante d’un projet ou d’un processus.
Acceptance	Acceptation	Voir Critères d’acceptation d’un service.
Access Management	Gestion des Accès	(Exploitation de Services) Le processus responsable d’autoriser les utilisateurs à faire usage des services des TI, des données ou autres actifs. La Gestion de l’accès contribue à protéger la confidentialité, l’intégrité et la disponibilité des actifs en assurant que seuls les utilisateurs autorisés peuvent accéder ou modifier les actifs. La Gestion de l’accès est parfois appelée Gestion des Droits ou Gestion de l’Identification.
Access Management	Gestion des Accès		Account Manager	Chargé de clientèle	(Stratégie de Services) Un rôle très proche de celui du Gestionnaire des Relations Business, mais qui comporte davantage d’aspects commerciaux. Il a principalement en charge les Clients Externes.
Accounting	Comptabilité	(Stratégie de Services) Le processus qui est chargé d’identifier les coûts réels de fourniture des services des TI, de les comparer avec les budgets prévus et de gérer les écarts avec le budget.
Accounting	Comptabilité		Accredited	Accrédité	Officiellement autorisé à prendre en charge un Rôle. Par exemple, une personne accréditée ou un organisme accrédité peut être autorisée à fournir une formation ou à procéder à des Audits.
Active Monitoring	Surveillance active	(Exploitation de Services) Surveillance d’un élément de configuration ou d’un service informatique à l’aide de vérifications régulières automatisées mettant en évidence son état actuel.
Active Monitoring	Surveillance active	Voir Surveillance passive.
Activity	Activité	Ensemble d’actions permettant d’obtenir un résultat spécifique. Les activités sont habituellement définies sous la forme de parties de processus ou de plans et sont documentées dans des procédures.
Agreed Service Time (AST)	Temps de service convenu (AST)	(Conception de services) Synonyme d’Heures de Service, communément employé dans le calcul de la Disponibilité.
Agreed Service Time (AST)	Temps de service convenu (AST)	Voir Temps de disponibilité.
Agreement	Accord	Document décrivant un arrangement formel entre deux parties ou plus. Un accord exécutoire ne devient légal que s’il fait partie d’un contrat.
Agreement	Accord	Voir Accord sur les niveaux de service, Accord sur les niveaux opérationnels.
Alert	Alerte	(Exploitation de Services) Avertissement qu’un seuil a été atteint, que quelque chose a changé, ou qu’une panne s’est produite. Les avertissements sont souvent créés et gérés par les outils de Gestion du Système et sont gérés par le Processus de Gestion des Événements.
Analytical Modelling	Modélisation analytique	(Stratégie de Services) (Conception de services) (Amélioration de la Continuité du Service) Technique employant des modèles mathématiques pour prévoir le comportement d’un élément de configuration ou d’un service informatique. Les modèles analytiques sont fréquemment employés dans la Gestion de la capacité et la Gestion de la disponibilité. Voir Modélisation.
Application	Application	Logiciel fournissant les fonctions nécessaires à un service informatique. Une application est exécutée sur un ou plusieurs serveurs ou clients.
Application	.	Voir Gestion des applications, Portefeuille d’applications.
Application Management	Gestion des Applications	(Conception de services) (Exploitation de Services) La fonction responsable de la gestion des applications tout au long de leur cycle de vie.
Application Management	Gestion des Applications		Application Portfolio	Portefeuille des applications	(Conception de services) Une base de données ou un document structuré servant à gérer les applications tout au long de leur cycle de vie. Le portefeuille d’applications contient les attributs clés de toutes les applications. Le portefeuille d’applications peut être implanté sous la forme d’une partie du portefeuille des services ou du système de gestion des configurations.
Application Service Provider (ASP)	Fournisseur de services applicatifs (ASP)	(Conception de services) Un fournisseur de service externe qui fournit des services informatiques à l’aide d’applications hébergées dans les locaux du fournisseur de service. Les utilisateurs accèdent aux applications au moyen de connexions réseau avec le fournisseur de service.
Application Service Provider (ASP)	Fournisseur de services applicatifs (ASP)		Application sizing	Dimensionnement des applications	(Conception de services) Activité ayant en charge la compréhension des besoins en ressources nécessaires pour soutenir une nouvelle application, ou un changement majeur apporté à une application existante. Le dimensionnement des applications contribue à ce que le service des TI atteigne ses Objectifs de Niveau de Service convenus en termes de capacité et de performances.
Architecture	Architecture	(Conception de services) Structure d’un système ou d’un service informatique, incluant les relations des composants les uns avec les autres et avec leur environnement. L’architecture inclut également les standards et les principes qui régissent la conception et l’évolution du système.
Assembly	Assemblage	(Transition de Services) Un élément de configuration élaboré à partir d’un certain nombre d’autres éléments de configuration. Par exemple un élément de configuration serveur peut contenir des éléments de configuration pour les cartes-mères, les disques durs, les cartes mémoire, etc ; un élément de configuration de service informatique peut contenir plusieurs matériels, logiciels et d’autres éléments de configuration.
Assembly	Assemblage	Voir Éléments de configuration d’un composant, Construction.
Assessment	Évaluation	Inspection et analyse permettant de vérifier qu’un standard ou un ensemble de principes a bien été suivi, que les enregistrements sont précis ou que les objectifs d’efficience et d’efficacité ont été atteints. Voir Audit.
Asset	Actif	(Stratégie de Services) Toute ressource ou capacité. Les actifs d’un fournisseur de service regroupent tout ce qui peut contribuer à la fourniture d’un service. Les actifs peuvent appartenir à une des catégories suivantes : Gestion, Organisation, Processus, Compétences, Personnel, Informations, Applications, Infrastructure, et Capital financier.
Asset Management	Gestion des Actifs	(Transition de Services) La gestion des actifs est le processus en charge du suivi et du rapport de la valeur ainsi que de la possession des actifs financiers tout au long de leur cycle de vie. La gestion des actifs fait partie d’un processus global de gestion des actifs de service et de gestion des configurations. Voir Registre des actifs.
Asset Register	Liste des actifs	(Transition de Services) Liste des actifs, incluant leur possesseur et leur valeur. Le registre des actifs est maintenu à jour par la Gestion des actifs.
Asset Register	Liste des actifs		Attribute	Attribut	(Transition de Services) Une information concernant un élément de configuration. Par exemple, le nom, l’emplacement, le numéro de version et le coût. Les attributs des éléments de configuration sont enregistrés dans la Base de Données de Gestion des Configurations (CMDB). Voir Relations.
Audit	Audit	Inspection et vérification formelle permettant de s’assurer qu’un standard ou un ensemble de principes a bien été suivi, que les enregistrements sont précis ou que les objectifs d’efficience et d’efficacité ont été atteints. Un audit peut être effectué par des groupes internes ou externes.
Audit	Audit	Voir Certification, Évaluation.
Authority Matrix	Matrice des responsabilités	Synonyme de RACI. (Responsible, Accountable, Consulted, Informed)
Automatic Call Distribution (ACD)	Distribution automatique d’appels (ACD)	(Exploitation de Services) Usage d’une technologie de l’information permettant de diriger un appel téléphonique vers la personne la plus compétente dans un laps de temps le plus court possible. L’ACD est aussi appelée Distribution d’appel automatisé.
Availability	Disponibilité	(Conception de services) Capacité d’un élément de configuration ou d’un service des TI à réaliser sa fonction convenue lorsque c’est nécessaire. La disponibilité est déterminée par la fiabilité, la facilité de maintenance, la facilité de service, la performance et la sécurité. La disponibilité est habituellement calculée sous la forme d’un pourcentage. Ce calcul est basé le plus souvent sur le temps de service convenu et le Temps d’indisponibilité. La meilleure pratique consiste à calculer la disponibilité en se basant sur les mesures du service des TI effectuées côté Business.
Availability Management	Gestion de la Disponibilité	(Conception de services) Processus chargé de définir, d’analyser, de planifier, de mesurer et d’améliorer tous les aspects de la disponibilité des services des TI. La Gestion de la disponibilité est chargée de s’assurer que la disponibilité de tous les Rôles, Outils, Processus, Infrastructures, etc… des TI est adaptée aux Objectifs de Niveau de Service convenus.
Availability Management Information System (AMIS)	Système d’information de la Gestion de la Disponibilité (AMIS)	(Conception de services) Répertoire virtuel des données de la gestion de la disponibilité, habituellement stocké dans des lieux physiques distincts.
Availability Management Information System (AMIS)		Voir Système de gestion des connaissances du service.
Availability Plan	Plan de disponibilité	(Conception de services) Plan permettant de s’assurer que les besoins en disponibilité des services des TI, actuels et futurs, peuvent être fournis de manière rentable.
Back-out	retour à l’état inital	Synonyme de Remède.
Backup	Copie de sauvegarde (Backup)	(Conception de services) (Exploitation de Services) Copie des données permettant de protéger l’original de toute perte d’intégrité ou de disponibilité.
Balanced Scorecard	Tableau de bord équilibré	(Amélioration continuelle du service) Un outil de gestion développé par le Dr. Robert Kaplan (Harvard Business School) et David Norton. Un tableau de bord équilibré permet de décomposer une stratégie en Indicateurs Clé de Performance (KPI). Les performances comparées aux KPI servent à démontrer comment la stratégie a été élaborée. Un tableau de bord équilibré est composé de 4 zones principales, chacune comprenant un petit nombre de KPI. Ces 4 zones sont considérées à des niveaux différents de détails par l’ensemble de l’organisation.
Baseline	Base de référence	(Amélioration continuelle du service) Une mesure ou image servant de point de référence. Par exemple :
		• Une base de référence ITSM peut servir de point de départ pour mesurer l’effet d’un Plan d’Amélioration du Service.
		• Une base de référence de performance peut servir à mesurer l’évolution des performances dans le temps d’un service des TI.
		• Une base de référence de Gestion des Configurations peut permettre de restaurer une infrastructure des TI selon une configuration connue si un changement ou une mise en production a échoué.
Benchmark	Benchmark	(Amélioration continuelle du service) État enregistré de quelque chose à un moment précis. Un test de performance peut être effectué pour une configuration, un processus, ou tout autre ensemble de données. Par exemple, un test de performance peut servir à :
		• L’amélioration continuelle du service, afin d’établir l’état actuel des améliorations de gestion.
		• La Gestion de la Capacité, pour documenter les caractéristiques des performances pendant les opérations normales.
		• Voir Benchmarking, Base de référence
Benchmarking	Benchmarking	(Amélioration continuelle du service) Action de comparer un test de performance à une base de référence ou à une meilleure pratique. Le terme Benchmarking signifie également créer une série de tests de performance dans le temps, et comparer leurs résultats afin de mesurer la progression ou l’amélioration.
Best Practice	Meilleures pratiques	Activités ou processus dont le succès a été démontré et qui sont utilisés par de multiples organisations. L’ITIL est un exemple de meilleure pratique.
Brainstorming	Remue-méninges (brainstorming)	(Conception de services) Une technique favorisant la génération d’idées dans en mode collaboratif au sein d’une équipe. Les idées ne sont pas revues pendant la session de Brainstorming, mais à une étape suivante. Le Brainstorming est souvent employé par la Gestion des Problèmes pour identifier les causes possibles.
British Standards Institution (BSI)	British Standards Institution (BSI) – Institut de Normalisation Britannique	Organisme national des standards pour le Royaume-Uni ayant en charge leur création et leur évolution (équivalent de l’AFNOR en France et le BNQ au Québec). Voir http://www.bsi-global.com pour de plus amples informations.
British Standards Institution (BSI)		Voir ISO.
Budget	Budget	Consolidation des éléments financiers prévisionnels d’une organisation ou d’une unité opérationnelle, comprenant les prévisions de recettes et de dépenses sur une période donnée.
Budget	Budget	Voir Budgétiser, Planifier.
Budgeting	Budgétisation	Activité de prévision et de contrôle des budgets. Comprend un cycle de négociation périodique pour définir les budgets futurs (habituellement annuels) ainsi que la surveillance quotidienne et l’ajustement des budgets en cours.
Build	Construction	(Transition de Services) Activité qui consiste à assembler un certain nombre d’éléments de configurations afin de créer une partie d’un service des TI. Le terme Construction fait aussi référence à une mise en production dont la distribution a été autorisée. Par exemple Construction un serveur ou Construction d’un ordinateur portable.
Build	Construction	Voir Base de référence de configuration.
Build environment	Environnement de construction	(Transition de Services) Un environnement contrôlé où des applications, des services informatiques et autres constructions sont assemblés avant d’être transférés dans un environnement de test ou dans un environnement réel.
Business	Business	(Stratégie de Services) Une société dans son ensemble ou une Organisation composée d’un certain nombre d’unités Business. Dans le contexte de l’ITSM, le terme Business inclut le secteur public et les organisations non commerciales, ainsi que les compagnies. Un fournisseur de services informatiques fournit des services informatiques à un Client au sein d’un Business. Le fournisseur de services informatiques peut faire partie du même Business que ses Clients (fournisseur de services interne) ou faire partie d’un autre Business (fournisseur de services externe).
Business	Business		Business Capacity Management (BCM)	Gestion de la Capacité Business (BCM)	(Conception de services) Dans le contexte de l’ITSM, la gestion de la capacité business est l’activité ayant en charge la compréhension des futures exigences du business afin de les intégrer dans le Plan de capacité.
Voir Gestion de la capacité du service.			Business Capacity Management (BCM)	Gestion de la Capacité Business (BCM)
Business case	Dossier business	(Stratégie de Services) Justification d’un élément de dépense significatif. Inclut des informations sur les coûts, les bénéfices, les options, les points de controverse, les risques et les problèmes potentiels.
Business case	Dossier business	Voir Analyse des Coûts et des Bénéfices.
Business Continuity Management (BCM)	Gestion de la Continuité du Business (BCM)	(Conception de services) Il s’agit du processus business en charge de la gestion des risques pouvant avoir un impact sérieux sur le business. La gestion de la continuité du business protège les intérêts des intervenants, la réputation de la marque et sa valeur en créant des activités. Le processus de la BCM implique la réduction des risques à un niveau acceptable et la planification de la reprise des processus business suite à une interruption de celui-ci. La BCM définit les objectifs, l’étendue et les besoins de la Gestion de la continuité du Service des TI.
Business Continuity Management (BCM)	Gestion de la Continuité du Business (BCM)		Business Continuity Plan (BCP)	Plan de continuité du business (BCP)	(Conception de services) Plan définissant les étapes nécessaires à la remise en fonction des processus business suite à une interruption. Ce plan doit aussi identifier les déclencheurs, les personnes impliquées, les moyens de communication, etc. Les plans de continuité des Services des TI représentent une part importante des plans de continuité du business.
Business Customer	Client business	(Stratégie de Services) Bénéficiaire d’un produit ou d’un service issu du business. Par exemple, si le business est la fabrication de véhicules alors le client business est celui qui achète un véhicule.	Business Continuity Plan (BCP)	Plan de continuité du business (BCP)
Business Customer	Client business		Business Impact Analysis (BIA)	Analyse d’impact sur le business (BIA)	(Stratégie de Services) La BIA est l’activité de la gestion de la continuité du business qui identifie les fonctions business vitales et leurs dépendances. Ces dépendances peuvent inclure des sous-traitants, des gens, d’autres processus business, des services informatiques, etc.
La BIA définit les besoins de la reprise des services des TI. Ces besoins incluent les objectifs de temps de reprise, les objectifs de point de reprise et les cibles de niveau de service minimum pour chacun des services informatiques.			Business Impact Analysis (BIA)	Analyse d’impact sur le business (BIA)
Business Objective	Objectif business	(Stratégie de Services) L’objectif d’un processus business, ou d’un business dans son ensemble. Les objectifs du business soutiennent la vision du business, servent de guide à la stratégie des TI et sont souvent soutenus par les services informatiques.
Business Objective	Objectif business		Business Operations	Opérations business	(Stratégie de Services) Il s’agit de l’exécution de la surveillance et de la gestion au jour le jour des processus business.
Business Perspective	Perspective business	(Amélioration continuelle du service) Une compréhension du fournisseur de service et des services des TI du point de vue du business et une compréhension du business du point de vue du fournisseur de service.	Business Operations	Opérations business
Business Perspective	Perspective business		Business Process	Processus business	Processus qui est possédé et exécuté par le business. Un processus business contribue à la fourniture d’un produit ou d’un service à un client du business. Par exemple, un revendeur peut avoir un processus d’achat qui contribue à fournir des services à ses clients business (sa clientèle). De nombreux processus business dépendent des services des TI.
Business Relationship Management (BRM)	Gestion des Relations Business (BRM)	(Stratégie de Services) Il s’agit du processus ou de la fonction en charge de maintenir une relation avec le business. La BRM inclut habituellement :	Business Process	Processus business
		• La gestion des relations du personnel avec les dirigeants du business.
		• La fourniture d’une entrée à la gestion du portefeuille des services.
		• L’assurance que le fournisseur de services informatiques a satisfait les besoins business du client.
		Ce processus a des liens étroits avec la gestion des niveaux de service.
Business Relationship Manager	Gestionnaire des Relations Business	(Stratégie de Services) Il s’agit d’un rôle en charge de maintenir une relation avec un ou plusieurs clients. Ce rôle est souvent combiné avec celui du gestionnaire des niveaux de service.
Business Relationship Manager	Gestionnaire des Relations Business	Voir Gestionnaire des comptes.
Business Service	Service business	Un service des TI qui soutient un processus business, par opposition à un service d’infrastructure qui est utilisé en interne par le fournisseur de services informatiques et n’est habituellement pas visible du business.
Business Service	Service business	Le terme Service au business signifie également un service qui est fourni aux clients du business par les unités business. Par exemple la fourniture de services financiers aux clients d’une banque, ou de denrées aux clients d’un magasin de détail. La réussite de la fourniture de services au business dépend souvent d’un ou de plusieurs services informatiques.
Business Service Management (BSM)	Gestion des Services Business (BSM)	(Stratégie de Services) (Conception de services) Il s’agit d’une approche de la gestion des services informatiques qui considère les processus business soutenus et la contribution apportée à la création de valeur du business fourni.
Business Service Management (BSM)	Gestion des Services Business (BSM)	Ce terme signifie également la gestion des services au business fournis à la clientèle du business.
Business Unit (BU)	Unité Business (BU)	(Stratégie de Services) Entité opérationnelle du business ayant ses propres plans, mesures, recettes et coûts. Chaque Unité Business possède ses actifs propres et les utilise pour créer de la valeur pour ses clients sous la forme de biens et de services.
Business Unit (BU)	Unité Business (BU)		Call	Appel	(Exploitation de Services) Un appel téléphonique au Centre de Services de la part d’un utilisateur. Un appel peut se concrétiser par la journalisation d’un incident ou d’une demande de service.
Call Center	Centre d’appels	(Exploitation de Services) Une Organisation ou une unité business qui gère un grand nombre d’appels téléphoniques reçus et émis.
Call Center	Centre d’appels	Voir Centre de Services.
Call Type	Type d’appel	(Exploitation de Services) Catégorisation des appels servant à classer les demandes reçues par le Centre de Services. Les types d’appels les plus fréquents sont incident, demande de service et réclamation.
Capability	Aptitude	(Stratégie de Services) L’aptitude d’une organisation, d’une personne, d’un processus, d’une application, d’un élément de configuration, ou d’un service des TI à mener à bien une activité. Les aptitudes sont les actifs intangibles d’une organisation.
Capability	Aptitude	Voir Ressouces.
Capability Maturity Model (CMM)	Capability Maturity Model (CMM)	(Amélioration continuelle du service) Le modèle de maturité d’aptitude pour logiciel (aussi connu sous le nom de CMM et SW-CMM) est un modèle servant à identifier les meilleures pratiques, afin d’améliorer le processus la maturité du processus. Le CMM a été développé par le SEI (Software Engineering Institute) de l’Université de Carnegie Mellon University. En 2000, le SW-CMM a fait l’objet d’une transition vers le modèle CMMI® (Capability Maturity Model Integration). Dès lors, le SEI a cessé de faire évoluer le modèle SW-CMM, ses méthodes d’évaluation associées, ni ses supports de formation.
Capability Maturity Model (CMM)	Capability Maturity Model (CMM)		Capability Maturity Model Integration (CMMI)	Capability Maturity Model Integration (CMMI)	(Amélioration continuelle du service) Le modèle de maturité d’aptitude à l’intégration est une approche d’amélioration de processus développée par le SEI (Software Engineering Institute) de Carnegie Mellon University. Le CMMI fournit aux organisations des éléments essentiels à l’efficacité des processus. Il peut servir à guider l’amélioration de processus au cours d’un projet, au sein d’une division ou d’une organisation dans son ensemble. Le CMMI contribue à intégrer des fonctions organisationnelles traditionnellement séparées, définit les buts et les priorités de l’amélioration des processus, établit les préceptes des processus qualité et fournit un point de référence pour l’évaluation des processus en cours. Voir http://www.sei.cmu.edu/cmmi pour de plus amples informations.
Voir CMM, Amélioration continuelle, Maturité.			Capability Maturity Model Integration (CMMI)	Capability Maturity Model Integration (CMMI)
Capacity	Capacité	(Conception de services) Le rendement maximum qu’un élément de configuration (CI) ou un service informatique puisse fournir en répondant aux Objectifs de Niveau de Service. Pour certains types de CI, la capacité peut être la taille ou le volume, par exemple un disque dur.
Capacity Management	Gestion de la Capacité	(Conception de services) Processus en charge de veiller à ce que la capacité des services des TI et de l’infrastructure des TI puisse répondre aux Objectifs de Niveau de Service d’une manière rentable et ponctuelle. La gestion de la capacité prend en compte toutes les ressources nécessaires pour fournir le service informatique et planifie les besoins du business à court, moyen et long terme.
Capacity Management Information System (CMIS)	Système d’information de Gestion de la Capacité (CMIS)	(Conception de services) Répertoire virtuel de toutes les données concernant la gestion de la capacité, habituellement stocké dans des lieux physiques distincts.
Capacity Management Information System (CMIS)	Système d’information de Gestion de la Capacité (CMIS)	Voir Système de gestion des connaissances du service.
Capacity Plan	Plan de capacité	(Conception de services) Le plan de capacité sert à gérer les ressources nécessaires à la fourniture des services informatiques. Ce plan contient des scénarios correspondant à différentes prévisions d’exigences du business, ainsi que des options cotées pour répondre aux Objectifs de Niveau de Service convenus.
Capacity Planning	Planification de la capacité	(Conception de services) Activité au sein de la gestion de la capacité ayant en charge la création d’un plan de capacité.
Capital Expenditure (CAPEX)	Frais d’investissement (CAPEX)	(Stratégie de Services) Le coût d’achat d’un bien qui deviendra un actif financier, par exemple équipement informatique et immeubles. La valeur de l’actif est amortie sur plusieurs périodes comptables.
Capital Item	Elément d’investissement	(Stratégie de Services) Un actif qui est intéressant pour la gestion financière car sa valeur est supérieure à une certaine valeur financière établie.
Capitalization	Capitalisation	(Stratégie de Services) Identification d’un coût majeur sous la forme de capital, sans acquisition d’actif. Ceci permet d’étaler l’impact du coût sur plusieurs périodes comptables. L’exemple le plus courant est le développement logiciel ou l’achat d’une licence logicielle.
Caterory	Catégorie	Groupe d’objets nommés ayant quelque chose en commun. Les catégories servent à regrouper des choses similaires. Par exemple, les types de coûts servent à regrouper des types de coûts similaires. Les catégories d’incidents servent à regrouper des types d’incidents similaires, les types de CI à regrouper des types d’éléments de configuration similaires.
Certification	Certification	Publier un certificat pour valider la conformité à un standard. La certification comporte un audit formel réalisé par une structure indépendante et accréditée. Le terme Certification signifie également décerner un certificat pour valider la qualification d’une personne.
Change	Changement	(Transition de Services) L’ajout, la modification ou la suppression de quoique que ce soit pouvant avoir un effet sur les services des TI. L’étendue doit inclure tous les services des TI, éléments de configuration, processus, documentation, etc…
Change Advisory Board (CAB)	Comité consultatif sur les changements (CAB)	(Transition de Services) Un groupe de personnes qui conseille le Gestionnaire des Changements dans l’évaluation, la définition des priorités et le calendrier des changements. Ce comité est habituellement composé de représentants de toutes les branches au sein du fournisseur de services informatiques, du business et des tierces parties tels que les sous-traitants.
Change Advisory Board (CAB)	Comité consultatif sur les changements (CAB)		Change case	Dossier de changement	(Exploitation de Services) Technique utilisée pour prévoir l’impact des changements proposés. Les études de changement emploient des scénarios spécifiques pour clarifier l’étendue des changements proposés et apporter l’aide d’une Analyse des Coûts et des Bénéfices.
Voir Étude de cas.			Change case	Dossier de changement
Change History	Historique des changements	(Transition de Services) Informations concernant tous les changements effectués sur un élément de configuration (CI) pendant sa durée de vie. L’historique des changements comporte tous les enregistrements de changements s’appliquant à ce CI.
Change Management	Gestion des Changements	(Transition de Services) Processus en charge de contrôler le cycle de vie de tous les changements. Le principal objectif de la gestion des changements et de rendre possible la mise en œuvre de changements bénéfiques avec un minimum d’interruption des services des TI.
Change Model	Modèle de changement	(Transition de Services) Une manière répétitive de traiter une catégorie de changements particulière. Un modèle de changement établit des étapes spécifiques prédéfinies qui seront suivies pour réaliser un changement de cette catégorie. Les modèles de changement peuvent être très simples, sans qu’aucune validation ne soit nécessaire (par ex. la réinitialisation d’un mot de passe) ou très complexes avec plusieurs étapes nécessitant des validations (par ex. une mise en production logicielle majeure).
Change Model	Modèle de changement	Voir Changement standard, Comité consultatif sur les Changements.
Change Record	Enregistrement d’un changement	(Transition de Services) Enregistrement contenant tous les détails d’un changement. Chaque enregistrement de changement documente le cycle de vie d’un seul changement. Un enregistrement de changement est créé pour chaque demande de changement ayant été reçue, même pour celles qui seront rejetées par la suite. Les enregistrements de changement doivent référencer les éléments de configuration qui ont été affectés par le changement. Ils sont stockés dans le Système de Gestion des Configurations.
Change Request	Demande de changement (RFC)	Équivalent de Request for Change (RFC).
Change Schedule	Calendrier des changements	(Transition de Services) Document qui établissant la liste de tous les changements approuvés et leurs dates d’implantation prévues. Un calendrier des changements est parfois appelé calendrier prévisionnel des changements, bien qu’il contienne quand même des informations sur les changements déjà effectués.
Change Window	Fenêtre des changements	(Transition de Services) Une période normale, convenue pendant laquelle des changements ou des mises en production peuvent être implantées avec un impact minimal sur les services. Les fenêtres de changement sont habituellement documentées dans les SLA.
Charging	Facturation	(Stratégie de Services) Demande de rétribution financière de la fourniture de services des TI. La facturation des services des TI est optionnelle, et de nombreuses organisations choisissent de considérer leur fournisseur de services informatiques comme un Centre de coût.
Chronological Analysis	Analyse chronologique	(Exploitation de Services) Technique contribuant à l’identification des causes possibles de problèmes. Toutes les données disponibles concernant le problème sont collectées et triées par date et période afin de fournir une périodicité détaillée. Ceci rend possible l’identification des événements ayant pu être déclenchés par d’autres.
CI Type	Type de CI	(Transition de Services) Catégorie servant à classer les CI. Le Type de CI identifie les attributs requis et les relations d’un enregistrement de Configuration. Les Types de CI les plus répandus sont : Matériel, Document, Utilisateur, etc.
Classification	Classification	Action d’assigner une catégorie à quelque chose. La classification permet d’assurer une gestion et des rapports cohérents. Les CI, incidents, problèmes, changements, etc. sont habituellement classés.
Client	Client	Terme générique représentant une clientèle, le business ou un client du business. Par exemple, le Gestionnaire de Clientèle peut être synonyme de Gestionnaire des comptes.
		Le terme Client peut également signifier :
		• Un ordinateur employé directement par un Utilisateur, par exemple un PC, un ordinateur de poche ou un poste de travail.
		• Une partie d’une application Client-Serveur à laquelle l’Utilisateur est directement interfacé. Par exemple un Client e-mail.
Closed	Clôturé	(Exploitation de Services) L’état final du cycle de vie d’un incident, d’un problème, d’un changement, etc. Lorsque l’état est devenu Fermé, plus aucune action n’est effectuée.
Closure	Clôture	(Exploitation de Services) Action de modifier l’état d’un incident, d’un problème, d’un changement, etc. en lui attribuant l’état Fermé.
COBIT	COBIT	(Amélioration continuelle du service) Le COBIT (Control Objectives for Information and related Technology) établit les préceptes et les meilleures pratiques de gestion des processus des TI. Le COBIT est publié par l’IT Governance Institute. Voir http://www.isaca.org/ pour de plus amples informations.
Code of Practice	Code de bonne pratique	Principe publié par un service public ou un organisme de standardisation, tel que ISO ou BSI. De nombreux standards sont basés sur un code de pratique et une spécification. Le code de pratique décrit les meilleures pratiques recommandées.
Cold Standby	Cold standby	Équivalent de Gradual Recovey (Reprise graduelle).
Commercial off the Shelf (COTS)	Article commercial prêt à l’emploi (COTS)	(Conception de services) Application logicielle ou Middleware pouvant être achetée auprès d’un fournisseur externe.
			Compliance	Conformité	Assurer qu’un standard ou un ensemble de principes est suivi, qu’une comptabilité correcte et cohérente est appliquée ou que diverses pratiques ont été employées.
			Component	Composant	Terme générique signifiant une partie d’un objet plus complexe. Par exemple, un système informatique peut être un composant d’un service informatique, une application peut être un composant d’une unité de mise en production. Les composants faisant l’objet d’une gestion doivent être des éléments de configuration.
Component Capacity Management (CCM)	Gestion de capacité des composants (CCM)	(Conception de services) (Amélioration continuelle du service) Processus en charge de comprendre la capacité, l’utilisation et les performances des éléments de configuration. Les données sont collectées, enregistrées et analysées afin d’être utilisées dans le Plan de capacité.
Component Capacity Management (CCM)	Gestion de capacité des composants (CCM)	Voir Gestion de la capacité de service.
Component CI	CI Composant	(Transition de Services) Élément de configuration faisant partie d’un assemblage. Par exemple, un CI carte-mère ou carte-mémoire peut faire partie d’un CI serveur.
Component Failure Impact Analysis (CFIA)	Analyse d’impact de la défaillance d’un composant (CFIA)	(Conception de services) Technique contribuant à l’identification de l’impact de la défaillance d’un CI sur les services informatiques. On dresse un tableau avec la liste des services des TI d’un côté et les CI de l’autre. Ce qui permet l’identification des CI cruciaux (ceux qui peuvent être la cause de la défaillance de plusieurs services des TI) et des services des TI fragiles (ayant plusieurs points de défaillance uniques).
Computer Telephony Integration (CTI)	Couplage téléphonie-informatique (CTI)	(Exploitation de Services) Terme générique recouvrant toutes sortes d’intégrations entre ordinateurs et systèmes de téléphonie. Ce terme sert principalement à désigner des systèmes où une application affiche des écrans détaillés relatifs aux appels reçus et émis.
Computer Telephony Integration (CTI)	Couplage téléphonie-informatique (CTI)	Voir Distribution automatique des appels, Réponse vocale interactive.
Concurrency	Accès concurrents	Mesure du nombre d’utilisateurs engagés dans une même opération au même moment.
Confidentiality	Confidentialité	(Conception de services) Principe de sécurité nécessitant que les données ne soient accessibles qu’à des personnes autorisées.
Configuration	Configuration	(Transition de Services) Terme générique servant à décrire un groupe d’éléments de configuration fonctionnant ensemble pour fournir un service informatique ou une partie significative d’un service informatique. Le terme Configuration sert également à décrire les réglages des paramètres d’un ou de plusieurs CI.
Configuration Baseline	Configuration de référence	(Transition de Services) Base de référence d’une configuration ayant été formellement convenue et qui est gérée via le processus de Gestion des changements. Une base de référence de configuration servira de base aux futurs constructions, mises en production et changements.
Configuration Control	Contrôle des configurations	(Transition de Services) Activité ayant en charge la gestion pertinente, des ajouts, modifications ou suppressions de CI. Par exemple, en soumettant une demande de changement ou une demande de service.
Configuration Identification	Identification des configurations	(Transition de Services) Activité ayant en charge la collecte des informations concernant les éléments de configuration et leurs relations ainsi que la saisie de ces informations dans la CMDB. L’Identification de la configuration est également responsable de l’étiquetage des CI eux-mêmes, afin que les enregistrements de configuration correspondants puissent être retrouvés.
Configuration Item (CI)	Elément de Configuration (CI)	(Transition de Services) Tout composant devant être géré afin de fournir un service des TI. Les informations concernant chaque CI sont enregistrées dans un enregistrement de configuration au sein du Système de gestion des configurations (CMS) où elles sont tenues à jour pendant tout son cycle de vie par la Gestion des configurations. Les CI sont sous le contrôle de la Gestion des changements. Les CI comprennent habituellement les services des TI, le matériel, les logiciels, les immeubles, les personnes et la documentation formelle tels que la documentation des processus et les SLA.
Configuration Management	Gestion des Configurations	(Transition de Services) Processus en charge de tenir à jour les informations concernant les éléments de configuration nécessaires pour fournir un service informatique ainsi que leurs relations. Ces informations sont gérées tout au long du cycle de vie du CI. La Gestion des configurations fait partie du processus global de Gestion des configurations et des actifs de service.
Configuration Management	Gestion des Configurations	(Transition de Services) Base de données servant à rassembler les enregistrements de configuration tout au long de leur cycle de vie. Le système de gestion des configurations tient à jour une ou plusieurs CMDB, chacune d’elles regroupant les attributs des CI, et leurs relations les uns avec les autres.
Database (CMDB)	Gestion des Configurations
Configuration Management System (CMS)	Système de Gestion des Configurations (CMS)	(Transition de Services) Ensemble d’outils et de bases de données servant à gérer les données de configuration d’un fournisseur de services informatiques. Le CMS comporte également des informations sur les incidents, problèmes, erreurs connues, changements et mises en production ; et peut aussi contenir des informations sur les employés, les sous-traitants, unités business, clients et utilisateurs. Le CMS comprend des outils pour collecter, stocker, gérer, mettre à jour et présenter les données concernant tous les éléments de configuration et leurs relations. Le CMS est tenu à jour par la gestion des configurations et est utilisé par tous les processus de gestion des services des TI.
Configuration Management System (CMS)	Système de Gestion des Configurations (CMS)	Voir Base de données de gestion des configurations, Système de gestion des connaissances du service.
Configuration Record	Enregistrement d’une configuration	(Transition de Services) Enregistrement contenant tous les détails d’un élément de configuration. Chaque enregistrement de configuration documente le cycle de vie d’un seul CI. Les enregistrements de configuration sont stockés dans une base de données de gestion des configurations.
Configuration Structure	Structure des configurations	(Transition de Services) Hiérarchie et autres relations entre tous les éléments de configuration composant une configuration.
Continual Service Improvement (CSI)	Amélioration Continue des Services (CSI)	(Amélioration continue du service) Une étape du cycle de vie d’un service des TI et le titre d’une des publications phare de l’ITIL. L’amélioration continuelle du service a en charge la gestion des améliorations des processus de gestion des services des TI et des services des TI eux-mêmes. La performance d’un fournisseur de services informatiques est continuellement mesurée et des améliorations sont apportées aux processus, aux services des TI et à l’infrastructure des TI afin d’accroître leur efficience, leur efficacité et leur rendement.
Continual Service Improvement (CSI)	Amélioration Continue des Services (CSI)	Voir Planifier-Faire-Vérifier-Agir.
Continuous Availability	Disponibilité continue	(Conception de services) Approche ou une conception visant à obtenir une disponibilité totale. Un service des TI à disponibilité continue n’a pas de période d’indisponibilité, qu’elle soit planifiée ou non.
Continuous operation	Exploitation continue	(Conception de services) Approche ou une conception visant à éliminer les périodes d’indisponibilité d’un service des TI. Notez que des éléments de configuration spécifiques peuvent être indisponibles alors que le service des TI reste disponible.
Contract	Contrat	Accord exécutoire légal entre deux parties ou plus.
Contract Portfolio	Portefeuille de contrats	(Stratégie de Services) Base de données ou un document structuré servant à gérer les contrats ou les accords de service entre un fournisseur de services informatiques et ses clients. Chaque service informatique fourni à un client doit avoir un contrat ou autre accord, qui sera listé dans le portefeuille de contrats.
Contract Portfolio	Portefeuille de contrats	Voir Portefeuille des services, Catalogue des services.
Control	Contrôle	Moyen permettant de gérer un risque, en s’assurant que l’objectif business est atteint, ou en s’assurant qu’un processus est suivi. Exemples de contrôles : Polices, Procédures, Rôles, RAID, verrous, etc. Un contrôle est parfois appelé contre-mesure ou mesure de sécurité.
Control	Contrôle	Le terme “contrôle” signifie également un moyen de gérer l’utilisation ou le comportement d’un élément de configuration, d’un système ou d’un service des TI.
Control Objectives for Information and related Technology (COBIT)	Control Objectives for Information and related Technology (COBIT)	Voir COBIT.
Control perspective	Perspective de contrôle	(Stratégie de Services) Approche de la gestion des services informatiques, processus, fonctions, actifs, etc. Il peut y avoir différentes perspectives de contrôle sur un même service informatique, processus, etc, permettant à différents individus ou à différentes équipes de s’intéresser à ce qui est important et qui relève de leur rôle spécifique. Exemples de perspectives de contrôle : la gestion réactive et proactive au sein des opérations des TI, ou une vision du cycle de vie d’une équipe pour un projet d’application.
Control Processes	Processus de contrôle	Groupe de processus ISO/IEC 20000 incluant la Gestion des changements et la Gestion des Configurations.
Core service	Service de base	(Stratégie de Services) Service informatique qui fournit les aboutissements désirés par un ou plusieurs clients.
Core service	Service de base	Voir Service de soutien, Package de services essentiels.
Core Service Package (CSP)	Package d’un service de base (CSP)	(Stratégie de Services) Description détaillée d’un service essentiel pouvant être partagé par un ou plusieurs Package de niveau de service.
Core Service Package (CSP)	Package d’un service de base (CSP)	Voir Package de services.
Cost	Coût	Quantité financière dépensée pour une activité, un service informatique ou une unité business spécifique. Les coûts consistent en coût réel (argent), notion de coût comme le temps des employés, et l’amortissement.
Cost Benefit Analysis	Analyse coûts-bénéfices	Activité ayant pour but d’analyser et de comparer les coûts et les bénéfices impliqués dans une ou plusieurs actions en cours.
Cost Benefit Analysis	Analyse coûts-bénéfices	Voir Étude de business, Valeur nette actuelle, Tarif de retour interne, Retour sur investissement, Valeur sur investissement.
Cost Center	Centre de coûts	(Stratégie de Services) Unité business ou un projet auquel des coûts sont affectés. Un centre de coût ne facture pas les services qu’il fournit. Un fournisseur de services informatiques peut fonctionner comme un centre de coût ou un centre de profit.
Cost effectiveness	Rentabilité	Mesure de l’équilibre entre l’efficacité et le coût d’un service, d’un processus ou d’une activité. Un processus rentable est celui qui atteint ses objectifs avec un coût minimum.
Cost effectiveness	Rentabilité	Voir KPI, Retour sur investissement, Rapport qualité/prix.
Cost Element	Elément de coût	(Stratégie de Services) Niveau moyen de catégorie auquel des coûts sont attribués en termes de budget et de comptabilité. Le niveau de catégorie le plus élevé étant le type de coût. Par exemple, un type de coût en “personnel” peut avoir des éléments de coût tels que, salaires, participation du personnel, dépenses, formation, heures supplémentaires, etc. Les éléments de coût peuvent encore être décomposés en unités de coût. Par exemple, l’élément de coût “dépenses” peut inclure des unités de coût, comme Hôtels, Transport, Repas, etc…
Cost Management	Gestion des coûts	(Stratégie de Services) Terme générique faisant référence au budget et à la comptabilité. Parfois synonyme de Gestion financière.
Cost Type	Type de coût	(Stratégie de Services) Niveau de catégorie le plus élevé auquel des coûts sont attribués, en termes de budget et de comptabilité. Par exemple, matériel, logiciel, personnel, locaux, sous-traitants transfert.
Cost Type	Type de coût	Voir Élément de coût, Type de coût.
Cost Unit	Unité de coût	(Stratégie de Services) Niveau de catégorie le plus bas auquel des coûts sont attribués, les unités de coût sont habituellement des éléments pouvant être aisément comptés (par ex. un nombre de personnes, des licences logicielles) ou des choses pouvant être aisément mesurées (ex. usage d’une carte-mère, électricité consommée). Les unités de coût sont incluses dans les éléments de coût. Par ex. l’élément de coût “dépenses” peut inclure des unités de coût, comme Hôtels, Transport, Repas, etc…
Cost Unit	Unité de coût	Voir Type de coût.
Countermeasure	Contre-mesure	Peut faire référence à n’importe quel type de contrôle. Le terme “Contre-mesure” est souvent utilisé pour faire référence à des mesures qui augmente la Résilience, la Tolérance de panne ou la Fiabilité d’un service des TI.
Course Corrections	Corrections de trajectoire	Changements apportés à un plan ou à une activité en cours d’avancement, pour garantir l’atteinte des objectifs fixés. Les corrections de cours résultent d’un processus de surveillance de l’avancement.
CRAMM	CRAMM	Méthodologie et outil d’analyse et de gestion des risques. Le CRAMM a été développé par le gouvernement britannique, mais est maintenant une propriété privée. De plus amples informations sont disponibles sur http://www.cramm.com/
Crisis Management	Gestion de Crises	Processus en charge de la gestion des implications plus larges de la Continuité du Business. L’équipe de gestion de crise est responsable des questions stratégiques, comme la gestion des relations avec les média et la confiance des actionnaires, c’est elle qui décide du déclenchement des Plans de Continuité du Business.
Critical Success Factor (CSF)	Facteur clé de succès (CSF)	Événement ou élément contribuant à la réussite d’un processus, d’un projet, d’un plan ou d’un service des TI. Les KPI servent à mesurer l’obtention de chaque CSF. Par exemple, un CSF de “protection des services des TI lors des changements” peut être mesuré par des KPI tels que “pourcentage de réduction des changements défectueux”, “pourcentage de réduction des changements causant des incidents”, etc.
Culture	Culture	Ensemble de valeurs qui sont partagées par un groupe de personnes, incluant certaines attentes sur la manière dont les gens doivent se comporter, sur leurs idées, leurs opinions et leurs pratiques.
Culture	Culture	Voir Vision.
Customer	Client	Personne qui achète des biens ou des services. Le client d’un fournisseur de service informatique est la personne ou le groupe qui définit et convient des cibles de niveau de service. Le terme “client” est aussi utilisé parfois de manière informelle pour désigner les utilisateurs, par exemple “il s’agit d’une organisation orientée Client”.
Customer Portfolio	Portefeuille de clients	(Stratégie de Services) Base de données ou un document structuré servant à enregistrer tous les clients du fournisseur de services informatiques. Le portefeuille de clients est le point de vue, qu’a le gestionnaire des relations business, des clients qui reçoivent les services des TI du fournisseur de services informatiques.
Customer Portfolio	Portefeuille de clients	Voir Portefeuille des contrats, Portefeuille des services.
Dashboard	Tableau de bord	(Exploitation de Services) Représentation graphique des Performances et de la Disponibilité globale d’un service des TI. Ces graphiques peuvent être mis à jour en temps réel et peuvent aussi être inclus dans les rapports de gestion et les pages web. Les tableaux de bord peuvent servir à soutenir la Gestion des niveaux de service, la Gestion des événements ou le Diagnostic d’un incident.
Data-to-Information-to-Knowledge-to-Wisdom (DIKW)	Data-to-Information-to-Knowledge-to-Wisdom (DIKW)	Une manière de comprendre les relations entre les données, les informations, les compétences et l’action prudente. Le schéma DIKW montre comment chacun de ses éléments influe sur les autres.
Data-to-Information-to-Knowledge-to-Wisdom (DIKW)	Data-to-Information-to-Knowledge-to-Wisdom (DIKW)		Definitive Media Library (DML)	Bibliothèque des supports définitifs (DML)	(Transition de Services) Un ou plusieurs endroits dans lesquels les versions définitives et approuvées de tous les éléments de configuration logiciels sont stockées en toute sécurité. La DML peut aussi contenir des CI associés tels que licences et documentation. La DML est une zone de stockage logicielle unique même si les lieux sont multiples. Tout logiciel de la DML est sous le contrôle de la Gestion des changements et de la Gestion des mises en production et est enregistré dans le Système de gestion des configurations. Seul un logiciel issu de la DML est acceptable pour être utilisé dans une mise en production.
Deliverable	Livrables	Quelque chose qui doit être fourni afin de satisfaire un engagement inscrit dans un accord sur les niveaux de service (SLA) ou dans un contrat.
Demand Management	Gestion de la Demande	Activités qui comprennent et influencent la demande du client envers des services et l’approvisionnement en capacité pour satisfaire ces demandes. À un niveau stratégique, la gestion de la demande peut impliquer l’analyse de Schémas d’activité business et de Profils Utilisateurs. À un niveau tactique, elle peut impliquer l’usage d’un coût différentiel afin d’encourager les clients à utiliser les services des TI à des moments moins fréquentés.
Demand Management	Gestion de la Demande	Voir Gestion de la capacité.
Deming Cycle	Cycle de Deming	Synonyme de Planifier-Faire-Vérifier-Agir (Plan-Do-Check-Act).
Dependency	Dépendance	Relation directe ou indirecte d’un processus ou d’une activité l’un avec l’autre.
Deployment	Déploiement	(Transition de Services) Activité en charge du déplacement de tout matériel, logiciel, documentation processus, etc. nouveau ou modifié dans son environnement réel. L’implantation fait partie du processus de gestion des mises en production et de l’implantation.
Deployment	Déploiement	Voir Déploiement.
Depreciation	Dépréciation	(Stratégie de Services) Mesure de la réduction de la valeur d’un actif tout au long de sa durée de vie. Elle est basée sur l’usure, la consommation ou autre facteur de réduction en termes de valeur économique utile.
Design	Conception	(Conception de services) Activité ou processus qui identifie les besoins puis définit une solution pour satisfaire ses besoins.
Design	Conception	Voir Conception de services.
Detection	Détection	(Exploitation de Services) Étape du cycle de vie d’un incident. La détection résulte du fait qu’un incident devient connu du fournisseur de services. La détection peut être automatique ou être le résultat de la journalisation d’un incident par un client.
Development	Développement	(Conception de services) Processus en charge de la création ou de la modification d’un service des TI ou d’une application. Sert aussi à désigner le rôle ou le groupe qui procède au travail de développement.
Development Environment	Environnement de développement	(Conception de services) Un environnement servant à créer ou à modifier des services des TI ou des applications. Les environnements de développement ne sont normalement pas soumis aux mêmes degrés de contrôle que les environnements de test ou les environnements réels.
Development Environment	Environnement de développement	Voir Développement.
Diagnosis	Diagnostic	(Exploitation de Services) Étape du cycle de vie d’un incident ou d’un problème. Le but du diagnostic est d’identifier une solution de contournement pour un incident ou la cause fondamentale d’un problème.
Diagnosis Script	Script de diagnostic	(Exploitation de Services) Ensemble structuré de questions structuré utilisé par l’équipe du centre de services pour s’assurer que les questions correctes sont posées et contribuer ainsi à classer, résoudre et assigner les incidents. Les scripts de diagnostic peuvent aussi être mis à la disposition des utilisateurs afin de les aider à diagnostiquer et résoudre leurs propres incidents.
Differential Charging	Facturation modulée (differential charging)	Une technique utilisée pour soutenir la gestion de la demande en facturant des valeurs différentes pour la même fonction de service informatique selon les heures.
Direct Cost	Coût direct	(Stratégie de Services) Coût de fourniture d’un service des TI pouvant être attribué dans sa globalité à un Client, un Centre de coût, un Projet, etc. Par exemple, le coût de la fourniture de serveurs ou de licences logicielles non partagés.
Direct Cost	Coût direct	Voir Coût indirect.
Directory Service	Service d’annuaire (Directory Service)	(Exploitation de Services) Application qui gère les informations concernant l’infrastructure des TI disponibles sur un réseau et les droits d’accès utilisateur correspondant.
Do Nothing	Ne rien faire	(Conception de services) Une option de reprise. Le fournisseur de services convient formellement avec le Client que la reprise de ce service des TI ne sera pas effectuée.
Document	Document	Information sous une forme lisible. Un document peut être papier ou électronique. Par exemple, une politique, un accord sur les niveaux de service (SLA), un enregistrement d’incident, un schéma d’aménagement d’une salle informatique.
Document	Document	Voir Enregistrement.
Downtime	Temps d’indisponibilité	(Conception de services) (Exploitation de Services) Période pendant laquelle un élément de configuration ou un service des TI n’est pas disponible, pendant la période convenue de service. La disponibilité d’un service des TI est souvent calculée à partir de la période convenue de service et de son temps d’indisponibilité.
Driver	Driver	Facteur influençant la stratégie, les objectifs ou les besoins. Par exemple une nouvelle législation ou les actions des concurrents.
Early Life Support (ELS)	Support de début de vie (ELS)	(Transition de Services) Soutien apporté à un service des TI, nouveau ou changé, juste après sa mise en production. Au cours d’un soutien précoce, le fournisseur de services des TI peut revoir les KPI, les niveaux de service ainsi que les seuils de surveillance et fournir des ressources supplémentaires à la Gestion des Incidents et des Problèmes.
Economies of scale	Économies d’échelle	(Stratégie de Services) Réduction du coût moyen qui est rendue possible en augmentant l’usage d’un service des TI ou d’un actif.
Economies of scale	Économies d’échelle	Voir Économies d’étendue.
Economies of scope	Économies de gamme	(Stratégie de Services) Réduction de coût qui est attribuée à un service des TI en utilisant un actif existant dans un autre but. Par exemple, fournir un nouveau service des TI à partir d’une infrastructure des TI déjà existante.
Economies of scope	Économies de gamme	Voir Économies d’échelle.
Effectiveness	Efficacité	(Amélioration continuelle du service) Mesure permettant de savoir si les objectifs d’un processus, d’un service ou d’une activité ont été atteints. Un processus ou une activité efficace est celui ou celle qui atteint les objectifs convenus.
Effectiveness	Efficacité	Voir KPI.
Efficiency	Efficience	(Amélioration continuelle du service) Mesure permettant de savoir si la bonne quantité de ressources a été utilisée pour un processus, un service ou une activité. Un processus efficient atteint ses objectifs avec un minimum de temps, d’argent, de personnel ou autres ressources.
Efficiency	Efficience	Voir KPI.
Emergency Change	Changement urgent	(Transition de Services) Un changement qui doit être introduit dès que possible. Par exemple pour résoudre un incident majeur ou implémenter un correctif de sécurité. Le processus de gestion des changements doit normalement avoir une procédure spécifique pour gérer les changements d’urgence.
Emergency Change	Changement urgent	Voir Comité consultatif des changements d’urgence.
Emergency Change Advisory Board (ECAB)	Comité consultatif sur les changements urgents (ECAB)	(Transition de Services) Un sous-ensemble du Comité consultatif des changements qui prend les décisions concernant les changements d’urgence à fort impact. Les membres de l’ECAB peuvent être nommés au moment de la réunion et la composition de l’ECAB dépend de la nature du changement d’urgence.
Environment	Environnement	(Transition de Services) Sous-ensemble de l’infrastructure des TI servant à un but particulier. Par exemple : Environnement réel, Environnement de test, Environnement de construction. Il est possible que plusieurs environnements partagent un même élément de configuration, par exemple les environnements de test, et réel peuvent utiliser différentes partitions d’un même ordinateur central. Sert également à désigner un environnement physique pouvant signifier un aménagement, l’air conditionné, un système électrique, etc.
Environment	Environnement	L’environnement sert également de terme générique pour désigner les conditions extérieures pouvant influencer ou affecter quelque chose.
Error	Erreur	(Exploitation de Services) Déroulement de conception ou un dysfonctionnement erroné qui provoque une défaillance d’un ou de plusieurs éléments de configuration ou services des TI Une faute commise par une personne ou un processus défectueux ayant un impact sur un CI ou un service des TI est aussi appelé une erreur.
Escalation	Escalade	(Exploitation de Services) Activité qui obtient des ressources supplémentaires lorsqu’elles sont nécessaires pour atteindre les cibles de niveaux de services ou satisfaire les attentes du client. L’escalade peut être nécessaire au sein de tout processus de gestion des services des TI, mais est le plus souvent associée à la gestion des incidents, à la gestion des problèmes et à la gestion des réclamations des clients. Il y a deux types d’escalades : Escalade fonctionnelle et Escalade hiérarchique.
ESourcing Capability Model for Client Organisations (eSCM-CL)	ESourcing Capability Model for Client Organisations (eSCM-CL)	(Stratégie de Services) Un cadre de travail destiné à guider les organisations dans leurs analyses et leurs prises de décisions sur les Modèles et les Stratégies de l’Approvisionnement en Service.
	(eSCM-CL)	L’eSCM-CL a été développé par Carnegie Mellon University.
		Voir eSCM-SP.
ESourcing Capability Model for Service Providers (eSCM-SP)	eSourcing Capability Model for Service Providers (eSCM-SP)	(Stratégie de Services) Un cadre de travail destiné à aider les fournisseurs de services des TI à développer leur Capacité de Gestion des services des TI à partir d’une perspective d’Approvisionnement en Service. L’eSCM-CP a été développé par Carnegie Mellon University.
		Voir eSCM-CL.
Estimation	Estimation	L’utilisation de l’expérience pour fournir une valeur approximative d’une Métrique ou d’un Coût. L’estimation est aussi employée dans la Gestion de la Capacité et la Gestion de la Disponibilité comme méthode de Modélisation la moins chère et la moins précise.
Evaluation	Évaluation	(Transition de Services) Processus en charge de l’estimation d’un service des TI, nouveau ou changé, afin de s’assurer que les risques ont été gérés et aider à déterminer s’il faut procéder au changement.
Evaluation	Évaluation	L’évaluation est aussi employée pour comparer un résultat actuel avec un résultat escompté, ou pour comparer une alternative à une autre.
Event	Événement	(Exploitation de Services) Un changement d’état ayant de l’importance pour la gestion d’un élément de configuration ou un service des TI.
Event	Événement	Le terme “événement” est aussi employé pour désigner une alerte ou une notification créée par un service des TI, un élément de configuration ou un outil de surveillance. Les événements requièrent habituellement du personnel d’exploitation des TI qu’il initie une action ce qui conduit le plus souvent à la journalisation d’incidents.
Event Management	Gestion des Événements	(Exploitation de Services) Processus en charge de la gestion des événements tout au long de leur cycle de vie. La gestion des événements est une des activités principales de l’exploitation des TI.
Exception report	Rapport d’exception	Document contenant tous les détails d’un ou de plusieurs indicateurs clés de performance (KPI) ou d’autres objectifs importants ayant dépassé des seuils définis. Par exemple, des cibles sur des accords sur les niveaux de service ( SLA) non atteintes ou sur le point de pas être atteintes, ou une mesure de performance indiquant un problème potentiel de capacité.
Expanded Incident Lifecycle	Cycle de vie détaillé d’un incident	(Gestion de la disponibilité) Étapes détaillées du cycle de vie d’un incident. Ces étapes sont la détection, le diagnostic, la réparation, la reprise, la restauration. Le cycle de vie étendu d’un incident aide à comprendre toutes les contributions à l’impact des incidents et à planifier comment mieux les contrôler et les réduire.
External Customer	Client externe	Un client qui travaille à un business différent de celui du fournisseur de services des TI.
External Customer	Client externe	Voir Fournisseur de service externe, Client interne.
External Metric	Métrique externe	Une mesure (métrique ‌) servant à mesurer la fourniture de services des TI à un client. Les mesures externes sont souvent définies par les Accords sur les Niveaux de Service (SLA) et font l’objet de rapports aux clients.
External Metric	Métrique externe	Voir Mesure interne.
External Service Provider	Fournisseur de service externe	(Stratégie de Services) Un fournisseur de services des TI qui fait partie d’une organisation différente de celle de son client. Un fournisseur de services des TI peut avoir à la fois des clients internes et des clients externes.
External Service Provider	Fournisseur de service externe	Voir Fournisseur de services de Type III.
External sourcing	Sourcing externe	Synonyme d’Externalisation.
Facilities Management	Gestion des Installations	(Exploitation de Services) Fonction en charge de la gestion de l’environnement physique où se trouve située (localisée ‌) l’infrastructure des TI. La Gestion des locaux inclut tous les aspects de la gestion de l’environnement physique. Par exemple, électricité et climatisation, gestion de l’accès au bâtiment, et surveillance des conditions environnementales.
Failure	Défaillance	(Exploitation de Services) Perte de la possibilité de fonctionner selon les spécifications ou de fournir le résultat requis. Le terme de Défaillance peut s’appliquer à des services des TI, des processus, des activités, des éléments de configuration, etc. Une défaillance est souvent la cause d’un incident.
Failure Modes and Effects Analysis (FMEA)	Analyse des modes et effets des défaillances (FMEA)	Approche permettant d’évaluer l’impact potentiel des défaillances. La FMEA implique d’analyser ce qui pourrait arriver suite à la défaillance de chacun des éléments de configuration jusqu’à leur effet sur le business. La FMEA est souvent utilisée par la gestion de la sécurité des informations et le Plan de continuité des services des TI.
Fast Recovery	Reprise rapide	(Conception de services) Une option de reprise également connue sous le nom de reprise immédiate (Hot Standby). Une provision est effectuée afin de reprendre le service des TI dans les plus brefs délais, normalement en moins de 24 heures. La reprise immédiate utilise habituellement un lieu (local ‌) fixe dédié, équipé de systèmes informatiques et de logiciels configurés prêts à fonctionner pour relancer les services des TI. Une reprise immédiate peut prendre jusqu’à 24 heures s’il est nécessaire de restaurer les données à partir de copies de sauvegarde.
Fault	Panne	Synonyme d’Erreur, dysfonctionnement.
Fault Tolerance	Tolérance aux pannes	(Conception de services) Possibilité qu’un service des TI ou un élément de configuration puisse continuer à fonctionner correctement après une défaillance d’une partie d’un composant.
Fault Tolerance	Tolérance aux pannes	Voir Résilience, Contre-mesure.
Fault Tree Analysis (FTA)	Analyse par arbre de pannes (FTA)	(Conception de services) (Amélioration continue du service) Technique pouvant être utilisée pour déterminer la chaîne des événements ayant conduit à un problème. L’analyse par arbre de panne représente la chaîne d’événements dans un schéma utilisant la notation Booléenne.
Financial Management	Gestion Financière	(Stratégie de Services) Fonction et processus en charge de la gestion du budget, de la comptabilité et des besoins en facturation d’un fournisseur de services des TI.
First-line Support	Support de premier niveau	(Exploitation de Services) Le premier niveau dans la hiérarchie des groupes de soutien impliqués dans la résolution des incidents. Chaque niveau contient davantage de compétences spécialisées ou dispose de davantage de temps ou d’autres ressources.
First-line Support	Support de premier niveau	Voir Escalade.
Fishbone diagram	Diagramme en arêtes de poisson (Fishbone Diagram)	Synonyme de diagramme d’Ishikawa
Fit for purpose	Adapté au besoin	Terme informel servant à décrire un processus, un élément de configuration, un service des TI etc, capable de satisfaire ses objectifs ou ses niveaux de service. Etre adapté nécessite une conception, une implémentation, un contrôle et un entretien adéquats.
Fixed cost	Coût fixe	(Stratégie de Services) Un coût qui ne varie pas avec l’usage d’un service des TI. Par exemple le coût du matériel pour un serveur.
Fixed cost	Coût fixe	Voir Coût variable.
Fixed Facility	Installation fixe	(Conception de services) Un bâtiment permanent, disponible pour être utilisé en cas de besoin par un Plan de continuité de services des TI.
Fixed Facility	Installation fixe	Voir Option de reprise, Lieu mobile.
Follow the Sun Support	Support type Follow the Sun	(Exploitation de Services) Une méthodologie permettant d’utiliser les centres de service et les groupes de soutien dans le monde entier afin de fournir un service 24×7. Les appels, incidents, problèmes et requêtes de service transitent d’un groupe à l’autre selon différents fuseaux horaires.
Fulfilment	Exécution	Effectuer des activités visant à satisfaire une nécessité ou une exigence. Par exemple en fournissant un nouveau service des TI, ou en répondant à une demande (requête ‌) de service.
Function	Fonction	Une équipe ou un groupe de personnes ainsi que les outils qu’ils utilisent pour mener à bien un ou plusieurs processus ou activités. Par exemple le centre de service.
		Le terme Fonction peut aussi avoir deux autres significations :
		• L’utilité d’un élément de configuration, d’une personne, d’une équipe, d’un processus ou d’un service des TI. Par exemple, une fonction d’un service d’e-mail peut être de stocker et de faire suivre les e-mails envoyés ; une fonction d’un processus business peut être de répartir les biens vers les clients.
		• Pour répondre correctement à l’utilité que l’on en attend “L’ordinateur fonctionne correctement”.
Functionnal Escalation	Escalade fonctionnelle	(Exploitation de Services) Transférer un incident, un problème ou un changement à une équipe technique ayant un plus haut degré d’expertise pour aider dans l’escalade.
Gap Analysis	Analyse de l’écart	(Amélioration continuelle du service) Activité ayant pour but de comparer deux ensembles de données et d’identifier leurs différences. L’analyse des écarts sert fréquemment à comparer un ensemble d’exigences avec ce qui a été réellement fourni.
Gap Analysis	Analyse de l’écart	Voir Benchmarking.
Governance	Gouvernance	S’assurer que les politiques et la stratégie sont réellement mises en œuvre et que les processus requis sont correctement suivis. La gouvernance inclut la définition des rôles et des responsabilités, la réalisation de mesures et de rapports, ainsi la réalisation d’actions pour résoudre tout problème identifié.
Gradual Recovery	Reprise graduelle	(Conception de services) Une option de reprise également connue sous le nom de Cold Standby. Une provision est effectuée afin de reprendre le service des TI dans un laps de temps de plus de 72 heures. La reprise graduelle utilise habituellement un lieu fixe ou mobile disposant d’un soutien environnemental et d’un câblage réseau, mais sans systèmes informatiques. Le matériel et le logiciel sont installés en tant qu’éléments du Plan de continuité de services des TI.
Guideline	Guide de bonnes pratiques (guideline)	Document décrivant les meilleures pratiques, qui recommandent ce qui doit être fait. La conformité à un principe n’est habituellement pas obligatoire.
Guideline	Guide de bonnes pratiques (guideline)	Voir Standard.
Help Desk	Centre d’assistance	(Exploitation de Services) Un point de contact pour les utilisateurs pour signaler (journaliser) des incidents. Un centre d’assistance est habituellement davantage orienté technique qu’un centre de services et ne fournit pas un point de contact unique pour toutes les interactions. Le terme “centre d’assistance” est souvent employé à la place de centre de services.
Hierarchic Escalation	Escalade hiérarchique	(Exploitation de Services) Informer ou impliquer davantage des niveaux plus seniors du management afin d’aider dans le processus d’escalade.
High Availability	Haute disponibilité	(Conception de services) Une approche ou un concept tendant à réduire (minimiser ‌) ou à cacher les effets d’une défaillance d’un élément de configuration sur les utilisateurs d’un service des TI. Les solutions à haute disponibilité sont conçues pour répondre à un niveau convenu de disponibilité et mettent en oeuvre des techniques telles que la tolérance de panne, la résilience et la reprise rapide afin de réduire le nombre d’incidents, ainsi que leur impact.
Hot Standby	Hot Standby	Équivalent de Fast Recovey (Reprise rapide) ou de Immediate Recovey (reprise immédiate).
Identity	Identité	(Exploitation de Services) Un nom unique servant identifier un utilisateur, une personne ou un rôle. L’identité permet de garantir les droits de cet utilisateur, personne ou rôle. Des exemples d’identités peuvent être un nom d’usage comme SmithJ ou de rôle comme “Gestionnaire des changements”.
Immediate Recovery	Reprise immédiate	(Conception de services) Une option de reprise également connue sous le nom de Hot Standby. Une provision est effectuée afin de reprendre le service des TI sans aucune perte de service. La reprise immédiate utilise habituellement des technologies de sites miroir, de sites dédoublés avec équilibrage des charges.
Impact	Impact	(Exploitation de Services) (Transition de Services) Mesure de l’effet d’un incident, problème ou changement sur les processus business. L’impact est souvent basé sur la manière dont les niveaux de service seront affectés. L’impact et l’urgence servent à assigner une priorité.
Incident	Incident	(Exploitation de Services) Une interruption non prévue (planifiée ‌) d’un service des TI ou une réduction de la qualité d’un service des TI. La défaillance d’un élément de configuration qui n’a pas encore eu d’impact sur le service est aussi un incident. Par exemple, la défaillance d’un seul des disques d’un ensemble de disques miroirs.
Incident Management	Gestion des Incidents	(Exploitation de Services) Processus en charge de la gestion du cycle de vie de tous les incidents. L’objectif principal de la Gestion des incidents est de rendre le service des TI aux utilisateurs aussi rapidement que possible.
Incident Record	Enregistrement d’un incident	(Exploitation de Services) Un enregistrement contenant les détails d’un incident. Chaque enregistrement d’incident documente le cycle de vie d’un seul incident.
Indirect Cost	Coût indirect	(Stratégie de Services) Un coût de fourniture d’un service des TI ne pouvant pas être affecté dans sa globalité à un Client spécifique. Par exemple, le coût de la fourniture de serveurs ou de licences logicielles partagés. Également nommé Frais généraux.
Indirect Cost	Coût indirect	Voir Coût direct.
Information Security Management (ISM)	Gestion de la Sécurité de l’Information (ISM)	(Conception de services) Processus qui assure la confidentialité, l’intégrité et la disponibilité des actifs, informations, données et services des TI d’une organisation. La Gestion de la Sécurité de l’Information fait habituellement partie d’une approche organisationnelle de la Gestion de la Sécurité avec une étendue plus large que la fourniture de services informatiques. Elle inclut la manipulation des papiers, l’accès aux bâtiments, les appels téléphoniques, etc, de toute l’organisation.
Information Security Management System (ISMS)	Systéme de Gestion de la Sécurité Informatique (ISMS)	(Conception de services) Le cadre de travail de la politique, des processus, standards, principes et outils qui assurent à une organisation qu’elle atteindra ses objectifs de Gestion de la Sécurité de l’Information.
Information Security Policy	Politique de sécurité informatique	(Conception de services) La politique qui gouverne l’approche que peut avoir une organisation en termes de Gestion de la Sécurité de l’Information.
Information Technology (IT)	Technologies de l’information (IT)	Usage de la technologie pour le stockage, la communication ou le traitement de l’information. La technologie inclut typiquement les ordinateurs et les télécommunications, les applications et autres logiciels. L’information peut inclure les données business, la voix, les images, la vidéo, etc. La technologie de l’information sert souvent à soutenir les processus business via les services des TI.
Infrastructure Service	Service d’Infrastructure	Un service des TI qui n’est pas utilisé directement par le business, mais est nécessaire au fournisseur de services des TI afin qu’il puisse fournir d’autres services des TI. Par exemple les services d’annuaire, les services d’attribution de nom ou de communication.
Insourcing	Internalisation	Synonyme d’approvisionnement interne.
Integrity	Intégrité	(Conception de services) Principe de sécurité qui assure que les données et les éléments de configuration ne sont modifiés que par un personnel et des activités autorisés. L’intégrité considère toutes les causes possibles de modification, y compris la défaillance logicielle et matérielle, les événements touchant à l’environnement et l’intervention humaine.
Interactive Voice Response (IVR)	Serveur vocal interactif (IVR)	(Exploitation de Services) Sorte de répartiteur d’appels basé sur l’intervention de l’utilisateur, comme l’appui sur une touche et des commandes orales, afin d’identifier la destination correcte des appels reçus.
Intermediate Recovery	Reprise intermédiaire	(Conception de services) Une option de reprise également connue sous le nom de Warm Standby. Des dispositions sont pruses afin de reprendre le service des TI dans un laps de temps compris entre 24 et 72 heures. La reprise intermédiaire utilise habituellement un lieu fixe ou mobile disposant de systèmes informatiques et de composants réseau. Le matériel et le logiciel doivent être configurés et les données doivent être restaurées à partir du Plan de continuité du service des TI.
Internal Customer	Client interne	Un client qui travaille dans la même entité ou organisation que celui du fournisseur de services des TI.
Internal Customer	Client interne	Voir Fournisseur de service interne, Client externe.
Internal Metric	Métrique interne	Une mesure utilisée par un fournisseur de services des TI pour surveiller l’efficience, l’efficacité ou le rendement des processus internes du fournisseur de services des TI. Les mesures internes sont habituellement rapportées au client du service des TI.
Internal Metric	Métrique interne	Voir Mesure externe.
Internal Rate of Return (IRR)	Taux de retour interne (IRR)	(Stratégie de service) Technique permettant d’aider à la prise de décisions concernant l’augmentation de capital. L’IRR calcule une somme permettant de comparer deux ou plusieurs possibilités d’investissements. Un IRR élevé indiqué un meilleur investissement.
Internal Rate of Return (IRR)	Taux de retour interne (IRR)	Voir Valeur actuelle nette, Retour sur investissement.
Internal Service Provider	Fournisseur de services interne	(Stratégie de service) Un fournisseur de services des TI qui fait partie de la même entreprise que celle de son client. Un fournisseur de services des TI peut avoir à la fois des clients internes et des clients externes.
Internal Service Provider	Fournisseur de services interne	Voir Fournisseur de services de Type I, Fournisseur de services de Type II, Internalisation.
Internal sourcing	Sourcing interne	(Stratégie de service) Utiliser exclusivement des fournisseurs de services des TI de sa propre entreprise pour gérer les services des TI.
Internal sourcing	Sourcing interne	Voir Approvisionnement en service, Fournisseur de services de Type I, Fournisseur de services de Type II.
International Organisation for Standardization (ISO)	International Organization for Standardization (ISO)	L’International Organisation for Standardization (ISO) est le plus grand développeur mondial de standards. L’ISO est une organisation non-gouvernementale qui regroupe un réseau d’instituts nationaux de standards dans 156 pays. De plus amples informations sur l’ISO sont disponibles à l’adresse : http://www.iso.org/
International Standards Organisation	Organisme International des Standards	Voir International Organisation for Standardization (ISO).
Internet Service Provider (ISP)	Fournisseur de services Internet (ISP)	Un fournisseur de services externe qui propose un accès à l’internet. La plupart des ISP fournit aussi d’autres services des TI tels que l’hébergement de sites web.
Invocation	Invocation	(Conception de service) Lancer les étapes définies par un plan. Par exemple déclencher le Plan de continuité du service des TI pour un ou plusieurs services des TI.
Ishikawa diagram	Diagramme d’Ishikawa	(Exploitation de Services) (Amélioration continue du service) Une technique qui aide à identifier toutes les causes possibles d’un problème. Inventée à l’origine par Kaoru Ishikawa, le résultat de cette de technique est un schéma ressemblant à une arrête de poisson.
ISO 9000	ISO 9000	Terme générique faisant référence à un certain nombre de standards et principes internationaux pour des systèmes de gestion de qualité. Voir http://www.iso.org/ pour de plus amples informations.
ISO 9000	ISO 9000	Voir ISO.
ISO 9001	ISO 9001	Standard international pour les systèmes de gestion de qualité.
ISO 9001	ISO 9001	Voir ISO 9000, Standard.
ISO/IEC 17799	ISO/IEC 17799	(Amélioration continue du service) Code de pratiques ISO pour la gestion de la sécurité de l’information.
ISO/IEC 17799	ISO/IEC 17799	Voir Standard.
ISO/IEC 20000	ISO/IEC 20000	Spécification et Code de pratiques ISO pour la gestion des services des TI. La norme ISO/IEC 20000 est alignée sur les meilleures pratiques ITIL.
ISO/IEC 20000	ISO/IEC 20000		ISO/IEC 27001	ISO/IEC 27001	(Conception de service) (Amélioration continue du service) Une Spécification ISO pour la gestion de la sécurité de l’information. Le Code de pratiques correspondant est ISO/IEC 17799.
Voir Standard.			ISO/IEC 27001	ISO/IEC 27001
IT Directorate	Direction informatique	(Amélioration continuée du service) Direction au sein d’un fournisseur de services, chargée de développer et de fournir des services des TI. Plus répandu dans les départements du gouvernement britannique.
IT Infrastructure	Infrastructure informatique	Tout ce qui est nécessaire : matériels, logiciels, réseaux, locaux, etc pour développer, tester, fournir, surveiller, contrôler ou fournir les services des TI. Le terme “Infrastructure des TI” concerne les technologies de l’information dans son ensemble, mais pas les personnes, ni les processus ou la documentation associées.
IT Operations	Opérations informatiques	(Exploitation de Services) Activités effectuées par le Contrôle de l’Exploitation des TI, incluant la gestion de console, le calendrier des tâches, la copie de sauvegarde et la restauration, ainsi que la gestion de l’impression et des données de sorties.
IT Operations	Opérations informatiques	L’exploitation des TI est également employée comme synonyme d’Exploitation de Services.
IT Operations Control	Contrôle des Opérations Informatiques	(Exploitation de Services) Fonction en charge de la surveillance et du contrôle des services des TI et de l’infrastructure des TI.
IT Operations Control	Contrôle des Opérations Informatiques	Voir Pont d’exploitation.
IT Operations Management	Gestion des Opérations Informatiques	(Exploitation de Services) La fonction assurée par le fournisseur de services des TI qui exécute les activités quotidiennes nécessaires pour gérer les services des TI et assurer le maintien en condition opérationnel l’infrastructure des TI. La Gestion de l’Exploitation des TI inclut le Contrôle de l’Exploitation des TI et la gestion des locaux.
IT Service	Service informatique	Il s’agit d’un service fourni à un ou plusieurs clients par un fournisseur de services des TI. Un service des TI est basé sur l’usage de technologies de l’information et soutient les processus métier du client. Un service des TI est composé d’une combinaison de personnes, de processus et de technologies ; et doit être défini dans un Accord sur les Niveaux de Service (SLA).
IT Service Continuity Management (ITSCM)	Gestion de la Continuité des Services Informatiques (ITSCM)	(Conception de service) Processus en charge de la gestion des risques pouvant avoir un impact grave sur les services des TI. L’ITSCM assure que le fournisseur de services des TI peut toujours fournir les niveaux de service minimum attendus, en réduisant le risque à un niveau acceptable et en planifiant la reprise des services des TI. L’ITSCM doit être conçue pour soutenir la gestion de la continuité du business.
IT Service Continuity Plan	Plan de continuité des services informatiques	(Conception de service) Plan définissant les étapes nécessaires à la reprise d’un ou de plusieurs services des TI. Ce plan doit aussi identifier les déclencheurs, les personnes impliquées, les moyens de communication, etc. Le plan de continuité de services des TI fait partie d’un plan de continuité du métier.
IT Service Management (ITSM)	Gestion des Services Informatiques (ITSM)	L’implantation et la gestion de services des TI de qualité, correspondant à des besoins métier. La gestion des services des TI est effectuée par les fournisseurs de services des TI grâce à un mélange adéquat de personnes, de processus et de technologies de l’information.
IT Service Management (ITSM)	Gestion des Services Informatiques (ITSM)	Voir Gestion des services.
IT Service Management Forum (itSMF)	IT Service Management Forum (itSMF)	Le forum de gestion des services des TI est une organisation indépendante dont le but est de promouvoir une approche professionnelle de la gestion des services des TI. L’itSMF est une organisation composée de bénévoles ayant des représentants dans de nombreux pays du globe (Chapitres itSMF). L’itSMF et ses membres contribuent au développement de l’ITIL et des standards de gestion de service associés.
IT Service Management Forum (itSMF)	IT Service Management Forum (itSMF)	Voir http://www.itsmf.com pour de plus amples informations.
IT Service Provider	Fournisseur de Service Informatique	(Stratégie de service) Un fournisseur de services des TI qui fournit des services informatiques à des clients internes et à des clients externes.
IT Steering Group (ISG)	Groupe de pilotage informatique (ISG)	Un groupe formel responsable d’assurer que les besoins métiers d’une part et les stratégies du fournisseur de services des TI et les plans d’autre part sont totalement alignés. Un Comité de direction des TI regroupe des représentants de la direction issus du business et du fournisseur de services des TI.
ITIL	ITIL	Un ensemble des meilleures pratiques de gestion des services des TI. L’ITIL appartient à l’OGC et consiste en une série de publications proposant des principes pour fournir des services des TI de qualité, ainsi que les processus et les moyens nécessaires pour les soutenir.
ITIL	ITIL	Voir http://www.itil.co.uk pour de plus amples informations.
Job Description	Description de poste	Un document définissant les rôles, responsabilités, compétences et savoir-faire exigés par une personne en particulier. La description d’un poste peut inclure de multiples rôles, par exemple les rôles du gestionnaire des configurations et du gestionnaire des changements peuvent être cumulés par une seule personne.
Job Scheduling	Ordonnancement des travaux (job scheduling)	(Exploitation de Services) Planification et gestion de l’exécution de travaux qui ont été requises par un service des TI. Les travaux ordonnancés sont gérés et le calendrier associé est sous la responsabilité de la gestion de l’Exploitation des TI et est le plus souvent automatisé à l’aide d’outils logiciels qui exécutent des tâches par lot ou en ligne selon un calendrier précis.
Kano Model	Modèle de Kano	(Stratégie de service) Un modèle développé par Noriaki Kano, qui sert à la compréhension des préférences du client. Le modèle de Kano prend en compte les attributs d’un service des TI regroupés par domaine tels que facteurs de base, facteurs d’excitation, facteurs de performance, etc.
Kepner & Tregoe Analysis	Analyse de Kepner & Tregoe	(Exploitation de Services) (Amélioration continue du service) Une approche structurée pour résoudre un problème. Le problème est analysé en termes de “quoi, où, quand et autres”. Les causes possibles sont identifiées. La cause la plus probable est testée. La cause réelle est vérifiée.
Key Performance Indicator (KPI)	Indicateur-clé de performance (KPI)	(Amélioration continue du service) Une mesure servant à gérer un processus, un service des TI ou une activité. De nombreuses mesures peuvent être faites, mais seules les plus importantes d’entre elles sont définies comme étant des KPI et servent réellement à gérer et à établir des rapports sur un processus, un service des TI ou une activité. Les KPI doivent être sélectionnés afin d’assurer que l’efficience, l’efficacité et le rendement sont tous gérés.
Key Performance Indicator (KPI)	Indicateur-clé de performance (KPI)	Voir Facteur de succès crucial.
Knowledge Base	Base de connaissances	(Transition de service) Une base de données logique contenant les données utilisées par le système de gestion des connaissances du service.
Knowledge Management	Gestion des Connaissances	(Transition de service) Processus en charge de rassembler, analyser, stocker et partager les connaissances et les informations au sein d’une organisation. Le but principal de la Gestion de connaissances est d’améliorer l’efficience en réduisant le besoin de redécouvrir des connaissances.
Knowledge Management	Gestion des Connaissances	Voir Données-Informations-Connaissances-Sagesse, Système de gestion des connaissances du service.
Known Error (KE)	Erreur connue (KE)	(Exploitation de Services) Un problème ayant une cause première et une solution de contournement documentées. Les erreurs connues sont créées et gérées tout au long de leur cycle de vie par la gestion des problèmes. Les erreurs connues peuvent aussi être identifiées par le développement ou les sous-traitants.
Known Error Database (KEDB)	Base de données des erreurs connues (KEDB)	(Exploitation de Services) Une base de données contenant tous les enregistrements des erreurs connues. Cette base de données est créée par la gestion des problèmes et utilisée par la gestion des incidents et des problèmes. La base de données des erreurs connues fait partie du Système de gestion des connaissances du service.
Known Error Record	Enregistrement d’erreur connue	(Exploitation de Services) Un enregistrement contenant les détails d’une erreur connue. Chaque enregistrement d’erreur connue documente le cycle de vie d’une erreur connue, ce qui inclut son état, sa cause première et la solution de contournement. Dans certaines implémentations, les erreurs connues sont documentées à l’aide de champs supplémentaires dans l’enregistrement d’un problème.
Livecycle	Cycle de vie	Les différentes étapes de la vie d’un service des TI, d’un élément de configuration, d’un incident, d’un problème, d’un changement, etc… Le cycle de vie définit les catégories d’état et les transitions d’un état à un autre sont autorisées. Par exemple :
		• Le cycle de vie d’une application comprend les besoins, la conception, la construction, le déploiement, l’exploitation, l’optimisation.
		• Le cycle de vie étendu d’un incident comprend la détection, la réponse, le diagnostic, la réparation, la reprise, la restauration.
		• Le cycle de vie d’un serveur peut comprendre : commandé, reçu, en test, en marche, au rebut, etc…
Line of Service (LOS)	Ligne de Service (LOS)	(Stratégie de service) Un service essentiel ou service de soutien ayant de multiples Ensemble de niveaux de services de niveaux de services. Une ligne de service est gérée par un responsable produit et chaque Ensemble de niveaux de services est conçu pour soutenir un segment particulier du marché.
Live	Opérationnel	(Transition de service) Fait référence à un service des TI ou à un élément de configuration actuellement utilisé pour fournir un service à un client.
Live environment	Environnement de production	(Transition de service) Un environnement contrôlé contenant des éléments de configuration utilisé pour fournir des services des TI à des clients.
Maintainability	Facilité de maintenance	(Conception de service) Mesure permettant de savoir dans quel délai et avec quelle efficacité un élément de configuration ou un service des TI peut être restauré pour retrouver un fonctionnement normal suite à une panne. La facilité de maintenance est souvent mesurée et rapportée sous le nom de MTRS. La facilité de maintenance sert également dans le contexte de développement d’un logiciel ou d’un service des TI pour signifier la possibilité de le changer ou de le réparer facilement.
Major Incident	Incident majeur	(Exploitation de Services) La plus haute catégorie d’impact pour un incident. Un incident majeur provoque une interruption significative du business.
Managed Services	Services gérés	(Stratégie de service) Une perspective des services des TI qui accentue le fait qu’ils sont gérés. Le terme “services gérés” peut être aussi synonyme de services des TI externalisés.
Management Information	Information de gestion	Information servant à soutenir une décision prise par la direction. L’information de gestion est souvent générée automatiquement par des outils soutenant les divers processus de gestion des services des TI. Les informations de gestion incluent souvent les valeurs des KPI tels que “Pourcentage de changements conduisant à des incidents”, ou “taux de résolution immédiate”.
Management of Risk (MoR)	Gestion du risque (MoR)	Méthodologie de l’OGC pour gérer les risques. La MoR inclut toutes les activités nécessaires pour identifier et contrôler l’exposition au risque pouvant avoir un impact sur l’obtention des objectifs business d’une organisation.
Management of Risk (MoR)	Gestion du risque (MoR)	Voir : http://wwwm-o-r.org/ pour de plus amples informations.
Management System	Système de gestion	Le cadre de travail des politiques, processus et fonctions qui assurent à une organisation de pouvoir atteindre ses objectifs
Manual Workaround	Solution de contournement manuelle	Solution de contournement nécessitant une intervention manuelle. Une solution de contournement manuelle est aussi utilisée sous le nom d’option de reprise, par laquelle le processus métier opère sans l’usage des services des TI. C’est une mesure temporaire habituellement combinée avec une autre option de reprise.
Marginal cost	Coût marginal	(Stratégie de service) Le coût pour continuer à fournir un service des TI. Le coût marginal ne comprend pas l’investissement déjà effectué, par exemple le coût de développement d’un nouveau logiciel et la fourniture d’une formation.
Market Space	Marché potentiel	(Stratégie de service) Toutes les opportunités qu’un fournisseur de services des TI peut exploiter afin de répondre aux besoins des clients. L’espace de marché identifie les éventuels services des TI qu’un fournisseur de services des TI peut espérer fournir.
Maturity	Maturité	(Amélioration continue du service) Une mesure de la fiabilité, de l’efficience et de l’efficacité d’un processus, d’une fonction, d’une organisation, etc. Les processus et fonctions les plus matures sont alignés sur les objectifs et les stratégies business de manière formelle et sont soutenus par un cadre de travail permettant une amélioration continuelle.
Maturity Level	Niveau de maturité	Intitulé d’un niveau dans un modèle de maturité, tel que le Modèle de maturité d’aptitude à l’intégration (CMMI) de Carnegie Mellon.
Mean Time Between Failures (MTBF)	Intervalle moyen entre les défaillances (MTBF)	(Conception de service) Mesure permettant de connaître et d’établir un rapport sur la fiabilité. Le MTBF est la durée moyenne pendant laquelle un élément de configuration ou un service des TI peut accomplir sa fonction attendue sans interruption. Il est mesuré à partir du moment où le CI ou le service des TI commence à fonctionner jusqu’à sa prochaine défaillance.
Mean Time Between Service Incidents (MTBSI)	Intervalle moyen entre les incidents de service (MTBSI)	(Conception de services) Mesure permettant de connaître et d’établir un rapport sur la fiabilité. Le MTBSI est le temps moyen entre deux pannes d’un système ou un service des TI. Le MTBSI est égal à MTBF + MTRS.
Mean Time To Repair (MTTR)	Temps moyen de réparation (MTTR)	(Conception de services) Le délai moyen pour réparer un élément de configuration ou un service des TI suite à une panne. Le MTTR est mesuré à partir du moment où le CI ou le service des TI tombe en panne jusqu’à sa réparation. Le MTTR n’inclut pas le temps nécessaire pour reprendre ou restaurer le CI ou le service des TI. Le MTTR est parfois employé incorrectement pour signifier le Délai moyen de restauration d’un service.
Mean Time To Restore Service (MTRS)	Temps moyen de restauration du service (MTRS)	(Conception de services) Le délai moyen pour restaurer un élément de configuration ou un service des TI suite à une défaillance. Le MTRS est mesuré à partir du moment où le CI ou le service des TI tombe en panne jusqu’à sa restauration complète afin qu’il retrouve sa fonction normale.
Mean Time To Restore Service (MTRS)	Temps moyen de restauration du service (MTRS)	Voir Facilité de maintenance, Délai moyen de réparation.
Metric	Métrique	(Amélioration continue du service) La mesure permet de mieux connaître et d’établir un rapport pour aider à la gestion d’un processus, d’un service des TI ou d’une activité.
Metric	Métrique	Voir KPI.
Middleware	Middleware	(Conception de service) Logiciel qui relie deux ou plusieurs composants logiciels . Un Middleware est habituellement acheté auprès d’un éditeur de logiciel, plutôt que développé par le fournisseur de services des TI.
Middleware	Middleware	Voir Prêt à l’emploi.
Mission Statement	Énoncé de mission	L’énoncé de mission d’une organisation est une description brève mais complète du but et des intentions générales de cette organisation. Il définit ce qui doit être accompli, mais ne dit pas comment y parvenir.
Model	Modèle	Une représentation d’un système, d’un processus, d’un service des TI ou d’un élément de configuration, etc. qui aide à comprendre ou à prévoir son futur comportement.
Modelling	Modélisation	Une technique servant à prévoir le futur comportement d’un système, d’un processus, d’un service des TI ou d’un élément de configuration, etc. La modélisation est fréquemment employée par la Gestion financière, la Gestion de la capacité et la Gestion de la disponibilité.
Monitor Control Loop	Boucle de contrôle	(Exploitation de Services) Surveiller le résultat d’une tâche, d’un processus, d’un service des TI ou d’un élément de configuration ; et le comparer à une valeur prédéfinie ; puis prendre les mesures appropriées en se basant sur cette comparaison.
Monitoring	Surveillance	(Exploitation de Services) Vérification répétée de l’état d’un élément de configuration, d’un service des TI ou d’un processus afin de générer un événement et de s’assurer que son état réel est connu.
Near-Shore	Near-shore	(Stratégie de service) Approvisionnement en service issu d’un pays proche de celui où est basé le client. Il peut s’agir de la fourniture d’un service des TI ou de fonctions de soutien, tel qu’un centre de services.
Near-Shore	Near-shore	Voir On-Shore, Off-Shore.
Net Present Value (NPV)	Valeur nette actuelle (NPV)	(Stratégie de service) Technique d’aide à la prise de décisions concernant une augmentation de capital. La NPV compare les entrées et les sorties d’argent. Une NPV positive indique qu’un investissement est envisageable.
Net Present Value (NPV)	Valeur nette actuelle (NPV)	Voir Taux de retour interne, Retour sur investissement.
Notional charging	Facturation notionnelle	(Stratégie de service) Une approche de la facturation des services des TI. Les coûts à facturer aux clients sont calculés et les clients sont informés des frais, mais l’argent n’est pas réellement transféré. La facturation notionnelle est parfois introduite afin d’attirer l’attention des clients sur les coûts qu’ils encourent ou comme préliminaire à l’introduction d’une facturation réelle.
Objective	Objectif	L’intérêt ou le but défini d’un processus, d’une activité ou d’une organisation dans sa globalité. Les objectifs sont habituellement exprimés par des cibles mesurables. Le terme “Objectif” est aussi utilisé de manière informelle pour signifier une exigence.
Objective	Objectif	Voir Aboutissement.
Off the Shelf	Prêt à l’emploi (off the shelf)	Synonyme de “du commerce”.
Office of Government Commerce (OGC)	Office of Government Commerce (OGC)	L’OGC est propriétaire de la marque ITIL (droits d’auteur et marque déposée). L’OGC est un bureau du gouvernement britannique qui soutient la fourniture du calendrier des acquisitions du gouvernement dans sa tâche en termes d’acquisition collaborative et en élevant les niveaux de capacité et de compétence d’acquisition des différents départements. Il fournit également un soutien aux projets complexes du secteur public.
Office of Public Sector Information (OPSI)	Office of Public Sector Information (OPSI)	L’OPSI accorde la licence Crown Copyright au matériel utilisé dans les publications ITIL. Il existe un département du gouvernement britannique qui fournit l’accès en ligne à la législation britannique, accorde les licences de réutilisation du matériel sous Crown Copyright, gère les informations du “Fair Trader Scheme”, tient à jour le “Registre des Actifs d’Information du gouvernement”, donne des conseils et établit les principes sur la publication officielle et le Crown Copyright.
Off-Shore	Off-shore	(Stratégie de service) Approvisionnement en service issu d’un endroit situé en dehors du pays où est basé le client,le plus souvent un autre continent. Il peut s’agir de la fourniture d’un service des TI ou de fonctions de soutien, tel qu’un centre de services.
Off-Shore	Off-shore	Voir On-Shore, Proximité (Near-Shore).
On-Shore	On-shore	(Stratégie de service) Approvisionnement en service issu d’un endroit situé dans le pays où est basé le client.
On-Shore	On-shore	Voir Off-Shore, Proximité (Near-Shore).
Operate	Exploiter	Accomplir ce qui est demandé. On dit d’un processus ou d’un élément de configuration qu’il fonctionne s’il fournit les résultats exigés. Fonctionner signifie également effectuer une ou plusieurs opérations.. Par exemple, des opérations quotidiennes sont nécessaires pour effectuer le maintien en condition opérationnel d’un ordinateur.
Operation	Exploitation ou Fonctionnement	(Exploitation de Services) Gestion quotidienne d’un service des TI, d’un système ou d’un élément de configuration ; etc. Une opération peut aussi signifier une activité ou une transaction prédéfinie. Par exemple, charger une bande magnétique, accepter de l’argent à un point de vente ou lire les données d’un disque dur.
Operational	Opérationnel	Le plus bas des trois niveaux de planification et de fourniture (Stratégique, Tactique, Opérationnel). Les activités opérationnelles incluent la planification ou la fourniture quotidienne ou à court terme d’un processus business ou d’un processus de gestion de service des TI.
Operational	Opérationnel	Le terme “Opérationnel” est aussi un synonyme de “En marche”.
Operational Cost	Coût opérationnel	Coût résultant du fonctionnement des services des TI. Souvent des paiements répétitifs. Par exemple les coûts en personnel, maintenance du matériel et électricité (également appelés “dépenses courantes” ou “dépenses de fonctionnement”).
Operational Cost	Coût opérationnel	Voir Augmentation de capital.
Operational Expenditure (OPEX)	Dépense opérationnelle (OPEX)	Synonyme de Coût opérationnel.
Operational Level Agrement (OLA)	Accord sur les niveaux opérationnels (OLA)	(Conception de service) (Amélioration continue du service) Un accord entre un fournisseur de services des TI et une autre partie de la même organisation. Un OLA soutient la livraison du fournisseur de services des TI en services aux clients. L’OLA définit les biens ou les services qui seront fournis et les responsabilités des deux parties. Par exemple, il doit y avoir un OLA :
		• entre le fournisseur de services des TI et un service Achats afin d’obtenir le matériel dans les délais attendus.
		• entre le centre de service et un groupe d’assistance afin de fournir la résolution d’un incident dans les délais attendus.
		Voir Accord sur les niveaux de service (SLA).
Operations Bridge	Salle de contrôle	(Exploitation de Services) Un lieu physique où les services des TI et l’infrastructure des TI sont surveillés et gérés.
Operations Control	Contrôle des opérations	Synonyme de Contrôle de l’exploitation des TI.
Operations Management	Gestion des Opérations	Synonyme de Gestion de l’Exploitation des TI.
Opportunity cost	Coût d’opportunité	(Stratégie de service) Un coût servant à prendre une décision pour choisir entre différents investissements. Le coût d’opportunité représente le revenu qui aurait été généré en utilisant les ressources d’une autre façon. Par exemple, le coût d’opportunité d’acheter un nouveau serveur peut inclure une activité d’amélioration du service qui n’a pas été effectuée et qui aurait eu un coût. L’analyse du coût d’opportunité fait partie des processus de prise de décision, bien qu’il ne soit pas traité comme un coût réel dans aucun relevé financier.
Optimise	Optimiser	Revoir, Planifier et demander des changements afin d’obtenir l’efficience et l’efficacité maximales d’un processus, d’un élément de configuration, d’une application, etc.
Organisation	Organisation	Une société, une entité légale ou autre institution. Quelques exemples d’organisations qui ne sont pas des sociétés : International Standards Organisation (ISO) ou itSMF. Le terme Organisation fait parfois référence à n’importe quelle entité disposant de personnes, de ressources et de budgets. Par exemple un projet ou une unité business.
Outcome	Résultat	Le résultat issu d’une activité ; du suivre d’un processus, de la fourniture d’un service des TI, etc. Le terme “Résultat” fait tout aussi bien référence à des résultats escomptés, qu’à des résultats réels.
Outsourcing	Externalisation	(Stratégie de Services) Utiliser un fournisseur de services externe pour gérer les services des TI.
Outsourcing	Externalisation	Voir Approvisionnement en service, Fournisseur de services de Type III.
Overhead	Frais généraux ou Surcharge	Synonyme de Coût indirect.
Pain Value Analysis	Analyse de la valeur de dérangement (pain value analysis)	(Exploitation de Services) Technique aidant à identifier l’impact sur le business d’un ou de plusieurs problèmes. Une formule sert à calculer la valeur de dérangement, elle est basée sur le nombre d’utilisateurs affectés, la durée de l’indisponibilité, l’impact sur chaque utilisateur et le coût pour le business (s’il est connu).
Pareto principle	Principe de Pareto	(Exploitation de Services) Technique permettant de définir la priorité des activités. Le principe de Pareto dit que 80% de la valeur d’une activité est créée par 20% de l’effort. L’analyse de Pareto est également utilisée dans la Gestion des problèmes afin de définir la priorité des causes possibles d’un problème lors d’une investigation.
Partnership	Partenariat	Une relation entre deux organisations qui implique de travailler en étroite collaboration pour des buts communs et un bénéfice mutuel. Le fournisseur de services des TI doit avoir un partenariat avec le business et avec les tierces parties cruciales dans la fourniture de services des TI.
Partnership	Partenariat	Voir Réseau de valeur
Passive Monitoring	Surveillance passive	(Exploitation de Services) Surveillance d’un élément de configuration, d’un service des TI ou d’un processus qui dépend d’une alerte ou d’une notification générée par lui-même et décrivant son état
Passive Monitoring	Surveillance passive	Voir Surveillance active.
Pattern of Business Activity (PBA)	Schéma d’activité Business (PBA)	(Stratégie de service) Profil de charge de travail d’une ou de plusieurs activités métier. Les schémas d’activité métier aident le fournisseur de service des TI à comprendre et à planifier les variations d’activités liées au métier. Voir Profil Utilisateur.
Percentage utilisation	Pourcentage d’utilisation	(Conception de service) La durée pendant laquelle un composant est occupé sur une période donnée. Par exemple, si une carte-mère est occupée pendant 1 800 secondes sur une période d’une heure, son utilisation est de 50%.
Performance	Performance	Mesure de ce qui est obtenu ou fourni par un système, une personne, une équipe, un processus ou un service des TI.
Performance Anatomy	Anatomie de la performance	(Stratégie de service) Une approche de la culture organisationnelle qui intègre et gère activement leadership et stratégie, développement des équipes, progrès technologique, gestion des performances et innovation.
Performance Management	Gestion des Performances	(Amélioration continue du service) Le processus en charge des activités quotidiennes de gestion de la capacité. Ceci inclut la supervision, les alertes liées à des dépassements de seuils, l’analyse des performances et leur optimisation, ainsi que la mise en œuvre (ou l’application) des changements relatifs à la performance et à la capacité.
Pilot	Pilote	(Transition de Services) La mise en œuvre d’un service des TI, d’une mise en production ou d’un processus dans un environnement réel sur un périmètre limité. Un pilote sert à réduire le risque, à obtenir un retour d’expérience et une validation des utilisateurs.
Plan	Plan	Une proposition détaillée qui décrit les activités et les ressources nécessaires pour atteindre un objectif. Par exemple, un plan pour implémenter un nouveau service ou processus. La norme IOS/IEC20000 requiert un plan pour gérer chaque processus de gestion des services des TI.
Plan-Do-Check-Act (PDCA) Model	Modèle Planifier-Faire-Vérifier-Agir (PDCA)	(Amélioration continue du service) Un cycle en quatre phases pour la gestion des processus attribué à Edward Deming. Planifier-Réaliser-Vérifier-Agir est aussi appelé roue de Deming.
		PLANIFIER : Concevoir ou réviser les processus qui soutiennent les services des TI.
		REALISER : Mettre en œuvre le plan et gérer les processus.
		VÉRIFIER : Mesurer les processus et les services des TI, les comparer avec les objectifs et produite un reporting.
		AGIR : Planifier et mettre en œuvre les changements afin d’améliorer les processus.
Planned Downtime	Temps d’indisponibilité planifié	(Conception de service) La période négociée pendant laquelle un service des TI n’est pas disponible. L’indisponibilité planifiée est souvent utilisée pour la maintenance, les mises à jour ou les tests.
Planned Downtime	Temps d’indisponibilité planifié	Voir Fenêtre de changement, Indisponibilité.
Planning	Planification	Une activité ayant pour but de créer un ou plusieurs plans. Par exemple, planification de la capacité.
PMBOK	PMBOK	Un standard de gestion de projet, tenu à jour et publié par le Project Management Institute. PMBOK signifie Project Management Body of Knowledge. Voir http://www.pmi.org/ pour de plus amples informations. Voir PRINCE2.
Policy	Politique	Attentes et intentions de gestion formellement documentées. Les politiques servent à diriger les décisions, et à assurer des développements et des implantations cohérents et appropriés des processus, standards, rôles, activités, Infrastructure des TI, etc.
Portable Facility	Installation portable	(Conception de service) Une construction préfabriquée ou un gros véhicule fourni par une tierce partie qui sera déplacé sur un site lorsqu’un plan de continuité des services des TI le nécessite.
Portable Facility	Infrastructure d’accueil mobile	Voir Option de reprise, Infrastructure des TI.
Post Implementation Review (PIR)	Revue post implémentation (PIR)	Une revue qui se produit après qu’un changement ou un projet a été implanté. Une PIR détermine si le changement ou le projet a été réussi et identifie les opportunités d’amélioration.
Practice	Pratique	Une façon de travailler ou une manière dont un travail doit être fait. Les pratiques peuvent inclure les activités, processus, fonctions, standards et principes.
Practice	Pratique	Voir Meilleures pratiques.
Prerequisite for Success (PFS)	Prérequis au succès (PFS)	Une activité qui doit être réalisée ou une condition qui doit être remplie pour permettre la mise en oeuvre réussie d’un plan ou d’un processus. Un PFS est souvent le résultat d’un processus qui se trouve être un atout nécessaire à un autre processus.
Pricing	Tarification	(Stratégie de service) Une activité qui définit le montant de la facturation due par les clients.
PRINCE2	PRINCE2	Standard de méthodologie du gouvernement britannique pour la gestion des projets. Voir http://www.ogc.gov.uk/prince2/ pour de plus amples informations.
PRINCE2	PRINCE2	Voir PMBOK
Priority	Priorité	(Transition de service) (Exploitation de Services) Une catégorie servant à identifier l’importance relative d’un incident, d’un problème ou d’un changement. La priorité est basée sur l’impact et sur l’urgence et sert à identifier le délai acceptable pour la mise en œuvre d’une action Par exemple, le SLA peut statuer que les incidents de Priorité 2 doivent être résolus en 12 heures.
Proactive Monitoring	Surveillance proactive	(Exploitation de Services)Type de supervision basé sur des modèles d’enchaînement d’événements permettant d’anticiper d’éventuelles défaillances futures.
Proactive Monitoring	Surveillance proactive	Voir Surveillance réactive.
Proactive Problem Management	Gestion proactive des Problèmes	(Exploitation de Services) Fait partie du processus de gestion des problèmes. L’objectif de la gestion proactive des problèmes est d’identifier et traiter les causes potentielles d’incidents avant qu’ils ne surviennent . La gestion proactive des problèmes analyse les enregistrements d’incidents et utilise les données collectées par les autres processus de gestion des services des TI pour identifier les tendances ou les problèmes significatifs.
Problem	Problème	(Exploitation de Services) La cause d’un ou de plusieurs incidents. Cette cause n’est pas forcément connue au moment de l’enregistrement du problème, et le processus de gestion des problèmes est alors chargé des nouvelles investigations.
Problem Management	Gestion des Problèmes	(Exploitation de Services) Le processus en charge de la gestion du cycle de vie de tous les problèmes. L’objectif principal de la Gestion des problèmes est d’éviter que des incidents ne surviennent et de minimiser l’impact des incidents qui ne pourraient pas être évités.
Problem Record	Enregistrement d’un problème	(Exploitation de Services) Un enregistrement contenant les détails d’un problème. Chaque enregistrement documente le cycle de vie d’un seul problème.
Procedure	Procédure	Un document contenant les étapes qui indiquent comment réaliser une activité. Les procédures sont définies comme faisant partie des processus.
Procedure	Procédure	Voir Instructions de travail.
Process	Processus	Un ensemble d’activités structurées conçues pour atteindre un objectif spécifique. Un processus traite une ou plusieurs entrées définies et les transforme en résultats (sortie). Un processus peut inclure la définition des tout rôles, responsabilités, outils et contrôles de gestion nécessaires à la fourniture de résultats de manière fiable. Un processus peut définir des politiques, des standards, des principes, des activités et des modes opératoires si c’est nécessaire.
Process Control	Contrôle de processus	Activité de planification et de mise sous contrôle d’un processus, ayant pour objectif d’accomplir le processus d’une manière efficace, efficiente et cohérente.
Process Manager	Gestionnaire de processus	Rôle dont la responsabilité est de réaliser la gestion opérationnelle d’un processus. Les responsabilités du gestionnaire de processus comprennent la planification et la coordination de toutes les activités nécessaires à son fonctionnement, sa surveillance et l’établissement de tableaux de bords sur le fonctionnement du processus. Il peut y avoir plusieurs gestionnaires de processus d’un même processus, par exemple des Gestionnaires des changements régionaux ou des Gestionnaires de la continuité des services des TI pour chaque centre de données. Le rôle du gestionnaire de processus est souvent confondu avec celui de propriétaire du processus, mais ces deux rôles peuvent être distincts dans les grandes organisations.
Process Owner	Propriétaire de processus	Rôle dont la responsabilité est de s’assurer qu’un processus est adapté aux besoins. Les responsabilités du propriétaire de processus comprennent la recherche de sponsors, la conception, la gestion des changements, l’amélioration continue du processus et de ses mesures. Ce rôle est souvent confondu avec celui de de gestionnaire du processus, mais ces deux rôles peuvent être distincts dans les grandes organisations.
Production Environment	Environnement de production	Environnement de production.
Profit Centre	Centre de profit	(Stratégie de service) Une unité business qui facture les services fournis. Un centre de profit peut être créé avec l’objectif de faire des profits, de rembourser des coûts ou de fonctionner à perte. Un fournisseur de service des TI peut fonctionner comme un centre de coûts ou un centre de profit.
pro-forma	Pro-forma	Un document modèle ou exemple contenant des données factices qui seront remplacées par les valeurs réelles lorsqu’elles seront disponibles.
Programme	Programme	Un certain nombre de projets et d’activités qui sont planifiés et gérés ensemble afin d’atteindre un objectif global et d’autres résultats.
Project	Projet	Une organisation temporaire, avec des personnes et autres actifs nécessaires pour atteindre un objectif ou d’autres résultats. Chaque projet a un cycle de vie qui comporte normalement les phases d’initialisation, de planification, d’exécution, de clôture, etc. Les projets sont habituellement gérés à l’aide d’une méthodologie formelle telle que PRINCE2.
Projected Service Availability (PSA)	Disponibilité projetée du service (PSA)	(manquant ‌) (le signe PSA figure dans la liste des acronymes).
Projected Service Availability (PSA)	Disponibilité projetée du service (PSA)	Planning de disponibilité de service revu et corrigé pour prendre en compte les arrêts planifiés de service.
Projected Service Outage (PSO)	Interruption projetée du service (PSO)	(Transition de service) Document qui identifie l’effet des changements, activités de maintenance et plans de test planifiés sur les niveaux de service attendus.
Projects IN Controlled Environments (PRINCE2)	PRojects IN Controlled Environments (PRINCE2)	Voir PRINCE2.
Qualification	Qualification	(Transition de service) Activité qui assure qu’une infrastructure des TI est adaptée et correctement configurée pour soutenir une application ou un service des TI.
Qualification	Qualification	Voir Validation.
Quality	Qualité	La capacité d’un produit, d’un service ou d’un processus à fournir la valeur escomptée. Par exemple, un composant matériel peut être considéré comme étant de bonne qualité s’il fonctionne comme on s’y attend et avec la fiabilité nécessaire. Le Processus Qualité requiert également la possibilité de surveiller l’efficacité et l’efficience, ainsi que leur amélioration si nécessaire.
Quality	Qualité	Voir Système de gestion de la qualité.
Quality Assurance (QA)	Assurance qualité (QA)	(Transition de service) Processus en charge d’assurer que la qualité d’un produit, d’un service ou d’un processus fournira la valeur escomptée.
Quality Management System (QMS)	Système de Gestion de la Qualité (QMS)	(Amélioration continuelle du service) Ensemble de processus en charge d’assurer que tout le travail effectué par une organisation est d’une qualité convenable pour satisfaire de manière fiable les objectifs business ou les niveaux de service.
Quality Management System (QMS)	Système de Gestion de la Qualité (QMS)	Voir ISO 9000.
Quick Win	Quick Win	(Amélioration continue du service) Une activité d’amélioration qui est sensée fournir un retour sur investissement à court terme avec relativement peu d’effort et à faible coût.
RACI	RACI	(Conception de services) (Amélioration continuelle du service) Modèle servant à définir les rôles et les responsabilités. RACI signifie Responsable de ses Actes, Consulté et Informé.
RACI	RACI	Voir Intervenants.
Reactive Monitoring	Surveillance réactive	(Exploitation de Services) Supervision qui prend les mesures adéquates en fonction d’un événement. Par exemple, soumettre une tâche par lot lorsque la tâche précédente est terminée ou journaliser un incident lorsqu’une erreur s’est produite.
Reactive Monitoring	Surveillance réactive	Voir Surveillance proactive.
Reciprocal Arrangement	Entente de réciprocité	(Conception de service) Une Stratégie de continuité de service. Un accord entre deux organisations qui partagent des ressources en cas d’urgence. Par exemple, l’espace d’une salle informatique ou un ordinateur central.
Record	Enregistrement	Document contenant les résultats ou d’autres sorties d’un processus ou d’une activité. Les enregistrements sont la preuve du fait qu’une activité a été réalisée, il peut s’agir d’un document papier ou électronique. Par exemple un rapport d’audit, l’enregistrement d’un incident ou les minutes d’une réunion.
Recovery	Reprise	(Conception de service) (Exploitation de Services) Revenir à un état normal de fonctionnement d’un élément de configuration ou d’un service des TI. La reprise d’un service des TI inclut souvent de récupérer les données dans un état connu et cohérent. Après une reprise, plusieurs actions peuvent être nécessaires avant que le service des TI ne soit rendu disponible aux utilisateurs (restauration).
Recovery Option	Option de reprise	(Conception de service) Une stratégie permettant de répondre à une interruption de service. Les stratégies les plus couramment employées sont Ne rien faire, Solution de contournement manuelle, Arrangement réciproque, Reprise graduelle, Reprise intermédiaire, Reprise rapide, Reprise immédiate. Les options de reprise peuvent faire usage de locaux spécifiques ou de locaux tierces partagés par plusieurs métiers.
Recovery Point Objective (RPO)	Objectif de point de reprise (RPO)	(Exploitation de Services)(Service Design) La quantité maximale acceptable de données pouvant être perdues lors de la restauration d’un service après une interruption. L’objectif d’un point de reprise est exprimé sous la forme d’une durée avant la panne. Par exemple, un objectif de point de reprise d’une journée peut être attendu grâce à des copies de sauvegarde quotidiennes. Les objectifs de point de reprise de chaque service des TI doivent être négociés, acceptés et documentés ; ils doivent servir d’exigences à la Conception de services et aux plans de continuité des services des TI.
Recovery Time Objective (RTO)	Objectif de temps de reprise (RTO)	(Exploitation de Services) (Service Design) La durée maximale accordée à la reprise d’un service après une interruption. Le niveau de service à fournir peut être inférieur aux cibles de niveau de service normales. Les objectifs de temps de reprise de chaque service des TI doivent être négociés, convenus et documentés.
Recovery Time Objective (RTO)	Objectif de temps de reprise (RTO)	Voir Analyse d’impact sur le business (BIA).
Redundancy	Redondance	Synonyme de Tolérance de panne.
Redundancy	Redondance	Le terme “Redondance” peut aussi prendre le sens d’obsolète ou inutile.
Relationship	Relation	Une connexion ou une interaction entre deux personnes ou deux objets. Dans la Gestion des relations métier, il s’agit de l’interaction entre deux fournisseurs de service des TI et le métier. Dans la Gestion des configurations, il s’agit d’un lien entre deux éléments de configuration qui définit une dépendance ou une connexion entre eux. Par exemple, des applications peuvent être liées aux serveurs sur lesquels elles sont installées, des services des TI peuvent avoir de nombreux liens avec tous les CI qui les composent.
Relationship Processes	Processus de gestion des relations	Le groupe de processus ISO/IEC 20000 comportant la Gestion des relations métier et la Gestion des sous-traitants.
Release	Mise en production	(Transition de service) Un ensemble de matériels, logiciels, documentations, processus et autres composants nécessaires pour déployer un ou plusieurs changements approuvés, dans les services des TI. Le contenu de chaque mise en production est géré, testé puis déployé comme une entité autonome.
Release and Deployment Management	Gestion des Déploiements et des Mises en Production	(Transition de service) Processus qui regroupe à la fois la préparation au déploiement et la mise en production.
Release Identification	Identification de mise en production	(Transition de service) Convention d’appellation servant uniquement à identifier une mise en production. L’identification de la mise en production inclut normalement une référence à un élément de configuration et à un numéro de version. Par exemple Microsoft Office 2003 SR2.
Release Management	Gestion des Mises en Production	(Transition de service) Processus en charge de la planification, du calendrier et du contrôle du mouvement des mises en production vers les environnements de test et réel. L’objectif principal de la Gestion des mises en production est de s’assurer l’intégrité de l’environnement de production et que des composants testés sont mis en production. La Gestion des mises en production fait partie de la Gestion des mises en production et des déploiements.
Release Process	Processus de mise en production	Nom utilisé par la norme ISO/IEC 20000 pour le groupe de processus qui inclut la Gestion des mises en production. Ce groupe n’inclut aucun autre processus.
Release Process	Processus de mise en production	Le processus de mise en production est aussi synonyme de processus de gestion des mises en production.
Release Record	Enregistrement d’une mise en production	(Transition de service) Enregistrement dans la CMDB qui définit le contenu d’une mise en production. Un enregistrement de mise en production a des relations avec tous les éléments de configuration qui sont affectés par la mise en production.
Release Unit	Unité de mise en production	(Transition de service) Composants d’un service des TI qui sont habituellement mis en production ensemble. Une unité de mise en production comprend suffisamment de composants pour exécuter une fonction utile. Par exemple, une unité de mise en production peut être un poste informatique PC comportant matériel, logiciel, licences, documentation, etc. Une autre unité de mise en production peut être une application de paye complète, incluant les Procédures d’exploitation et la formation de l’utilisateur.
Release Window	Fenêtre de mise en production	Synonyme de Fenêtre de changement.
Reliability	Fiabilité	(Conception de service) (Amélioration continue du service) Une mesure de la durée pendant laquelle un élément de configuration ou un service des TI peut exécuter sa fonction attendue sans interruption. Habituellement mesurée par le MTBF ou MTBSI. Le terme “Fiabilité” peut aussi servir à établir la probabilité selon laquelle un processus, une fonction, etc… fournira le résultat exigé.
Reliability	Fiabilité	Voir Disponibilité.
Remediation	Rattrapage	(Transition de service) Reprise à un état connu après l’échec d’un changement ou d’une mise en production.
Repair	Réparation	(Exploitation de Services) Remplacement ou correction d’un élément de configuration défaillant.
Request for Change (RFC)	Demande de changement (RFC)	(Transition de service) Une demande formelle de changement à effectuer. Une RFC comporte des détails sur le changement proposé et peut être enregistrée sur papier ou électroniquement. Le terme RFC est souvent utilisé à contresens pour signifier Enregistrement de changement ou le changement lui-même.
Request Fulfilment	Exécution des requêtes	(Exploitation de Services) Processus en charge de la gestion du cycle de vie de toutes les demandes de changement.
Requirement	Besoin	(Conception de service) Un énoncé formel de ce qui est nécessaire. Par exemple, une exigence de niveau de service, une exigence de projet, ou les Livrables exigés par un processus.
Requirement	Besoin	Voir Énoncé des exigences.
Resilience	Résilience	(Conception de services) La capacité d’un élément de configuration ou d’un service des TI à résister à une panne ou à avoir une reprise rapide suite à une défaillance. Par exemple, un câble blindé résistera mieux à la défaillance lorsqu’il sera soumis à une tension.
Resilience	Résilience	Voir Tolérance de panne.
Resolution	Résolution	(Exploitation de Services) Action de réparer la cause fondamentale d’un incident ou d’un problème ou de mettre en oeuvre une solution de contournement.
Resolution	Résolution	Dans la norme ISO/IEC 20000, le processus de résolution est le groupe qui inclut la gestion des incidents et des problèmes.
Resolution Process	Processus de résolution	Le groupe de processus de la norme ISO/IEC 20000 qui inclut la gestion des incidents et la gestion des problèmes.
Resource	Ressource	(Stratégie de service) Terme générique qui inclut le personnel, le budget alloué à l’infrastructure des TI, et tout autre élément pouvant contribuer à fournir un service des TI. Les ressources sont considérées comme les actifs d’une organisation.
Resource	Ressource	Voir Capacité, Actif de service.
Response Time	Temps de réponse	Mesure du temps nécessaire pour achever une opération ou une transaction. Utilisé par la gestion de la capacité comme mesure de la performance de l’infrastructure des TI et par la gestion des incidents comme la mesure du temps passé à répondre au téléphone ou à démarrer un diagnostic.
Responsiveness	Réactivité	Mesure du temps nécessaire pour répondre à quelque chose. Il peut s’agir du temps de réponse d’une transaction ou de la vitesse à laquelle un fournisseur de service des TI répond à un incident ou à une demande de changement.
Restoration of Service	Restauration de service	Voir Restaurer.
Restore	Restaurer	(Exploitation de Services) Action de rendre un service des TI aux utilisateurs après une réparation et une reprise suite à un incident. C’est l’objectif principal de la Gestion des incidents.
Retire	Retirer ou Supprimer	(Transition de service) Suppression définitive d’un service des TI ou d’un autre élément de configuration de l’environnement de production. La suppression est une phase du cycle de vie de la plupart des éléments de configuration.
Return on Investment (ROI)	Retour sur investissement (ROI)	(Stratégie de service) (Amélioration continuelle du service) Mesure du bénéfice espéré d’un investissement. Dans son sens le plus simple, il s’agit du bénéfice net rapporté par un investissement divisé par la valeur nette des actifs investis.
Return on Investment (ROI)	Retour sur investissement (ROI)	Voir Valeur nette actuelle (NPV), Valeur sur investissement.
Return to Normal	Retour à la normale	(Conception de service) Phase d’un plan de continuité de service des TI durant laquelle la totalité des opérations normales est reprise. Par exemple, si un autre centre de données a été utilisé, cette phase remettra en service le premier centre de données et restaurera la possibilité de déclencher à nouveau des plans de continuité de service des TI.
Release Window	Fenêtre de mise en production	Synonyme de Fenêtre de changement.
Reliability	Fiabilité	(Conception de services) (Amélioration continuelle du service) Une mesure de la durée pendant laquelle un élément de configuration ou un service des TI peut exécuter sa fonction convenue sans interruption. Habituellement mesurée par le MTBF ou MTBSI. Le terme “Fiabilité” peut aussi servir à établir la probabilité selon laquelle un processus, une fonction, etc… fournira le résultat exigé.
Reliability	Fiabilité	Voir Disponibilité.
Remediation	Rattrapage	(Transition de Services) Reprise à un état connu après l’échec d’un changement ou d’une mise en production.
Repair	Réparation	(Exploitation de Services) Remplacement ou correction d’un élément de configuration défaillant.
Request for Change (RFC)	Demande de changement (RFC)	(Transition de Services) Une proposition formelle de changement à effectuer. Une RFC comporte des détails sur le changement proposé et peut être enregistrée sur papier ou électroniquement. Le terme RFC est souvent utilisé à contresens pour signifier Enregistrement de changement ou le changement lui-même.
Request Fulfilment	Exécution des requêtes	(Exploitation de Services) Processus en charge de la gestion du cycle de vie de toutes les demandes de changement.
Requirement	Besoin	(Conception de services) Un énoncé formel de ce qui est nécessaire. Par exemple, une exigence de niveau de service, une exigence de projet, ou les Livrables exigés par un processus.
Requirement	Besoin	Voir Énoncé des exigences.
Resilience	Résilience	(Conception de services) La capacité d’un élément de configuration ou d’un service des TI à résister à une défaillance ou à avoir une reprise rapide suite à une défaillance. Par exemple, un câble blindé résistera mieux à la défaillance lorsqu’il sera soumis à une tension.
Resilience	Résilience	Voir Tolérance de panne.
Resolution	Résolution	(Exploitation de Services) Action de réparer la cause fondamentale d’un incident ou d’un problème ou d’implanter une solution de contournement.
Resolution	Résolution	Dans la norme ISO/IEC 20000, le processus de résolution est le groupe qui inclut la gestion des incidents et la gestion des problèmes.
Resolution Process	Processus de résolution	Le groupe de processus de la norme ISO/IEC 20000 qui inclut la gestion des incidents et la gestion des problèmes.
Resource	Ressource	(Stratégie de Services) Terme générique qui inclut le personnel, l’argent de l’infrastructure des TI, et tout autre élément pouvant contribuer à fournir un service des TI. Les ressources sont considérées comme les actifs d’une organisation.
Resource	Ressource	Voir Capacité, Actif de service.
Response Time	Temps de réponse	Mesure du temps nécessaire pour achever une opération ou une transaction.
Response Time	Temps de réponse	Utilisé par la gestion de la capacité comme mesure de la performance de l’infrastructure des TI et par la gestion des incidents comme la mesure du temps passé à répondre au téléphone ou à démarrer un diagnostic.
Responsiveness	Réactivité	Mesure du temps nécessaire pour répondre à quelque chose. Il peut s’agir du temps de réponse d’une transaction ou de la vitesse à laquelle un fournisseur de service des TI répond à un incident ou à une demande de changement.
Restoration of Service	Restauration du service	Voir Restaurer.
Restore	Restaurer	(Exploitation de Services) Action de rendre un service des TI aux utilisateurs après une réparation et une reprise suite à un incident. C’est l’objectif principal de la Gestion des incidents.
Retire	Suppression	(Transition de Services) Suppression définitive d’un service des TI ou autre élément de configuration de l’environnement opérationnel . La suppression est une phase du cycle de vie de nombreux éléments de configuration.
Return on Investment (ROI)	Retour sur investissement (ROI)	(Stratégie de Services) (Amélioration continuelle du service) Mesure du bénéfice espéré d’un investissement. Dans son sens le plus simple, il s’agit du bénéfice net rapporté par un investissement divisé par la valeur nette des actifs investis.
Return on Investment (ROI)	Retour sur investissement (ROI)	Voir Valeur nette actuelle (NPV), Valeur sur investissement.
Return to Normal	Retour à la normale	(Conception de services) Phase d’un plan de continuité du service des TI durant laquelle la totalité des opérations normales sont recouvrée s. Par exemple, si un autre centre de données a été utilisé, cette phase remettra en service le premier centre de données et restaurera la possibilité de déclencher à nouveau des plans de continuité du service des TI.
Review	Revue	Évaluation d’un changement, problème, processus, projet, etc. Les revues sont habituellement effectuées à des moments prédéfinis du cycle de vie et surtout après la fermeture. Le but d’une revue étant d’assurer que tous les livrables ont été fournis et d’identifier les opportunités d’amélioration.
Review	Revue	Voir Revue Post Implantation (PIR).
Rights	Droits	(Exploitation de Services) Droits ou permissions garanties à un utilisateur ou à un rôle. Par exemple, le droit de modifier des données particulières ou d’autoriser un changement.
Risk	Risque	Un événement possible pouvant causer une déficience ou une perte, ou affecter la possibilité d’atteindre des objectifs. Un risque se mesure par la probabilité d’une menace, la vulnérabilité d’un actif à cette menace et l’impact qu’il aurait s’il se produisait.
Risk Assessment	Évaluation des risques	Les étapes initiales de la gestion des risques. Analyser la valeur des actifs par rapport aux métiers, identifier les menaces envers ces actifs et évaluer comment chaque actif est vulnérable à ces menaces. L’évaluation du risque peut être quantitative (basée sur des données chiffrées) ou qualitative.
Risk Management	Gestion des risques	Processus en charge d’identifier, évaluer et contrôler les risques.
Risk Management	Gestion des risques	Voir Évaluation du risque.
Role	Rôle	Un ensemble de responsabilités, d’activités et d’autorités attribuées à une personne ou à une équipe. Le rôle est défini dans un processus. Une personne ou une équipe peut avoir plusieurs rôles, par exemple, les rôles de Gestionnaire des configurations et de Gestionnaire des changements peuvent être attribués à une même personne.
Rollout	Déploiement	(Transition de Services) Synonyme de Déploiement ( ! !). Souvent utilisé pour faire référence à des déploiements complexes ou en plusieurs phases ou à des déploiements sur de multiples lieux.
Root Cause	Cause première	(Exploitation de Services) La cause sous-jacente ou originelle d’un incident ou d’un problème.
Root Cause Analysis (RCA)	Analyse de la cause première (RCA)	(Exploitation de Services) Une activité qui identifie la cause fondamentale d’un incident ou d’un problème. La RCA se concentre typiquement sur les défaillances de l’infrastructure des TI.
Root Cause Analysis (RCA)	Analyse de la cause première (RCA)	Voir Analyse de la défaillance du service.
Running Costs	Coûts de fonctionnement	Synonyme de Coûts opérationnels
Scalability	Extensibilité	La capacité d’un service des TI, processus, élément de configuration, etc à accomplir sa fonction convenue lorsque la charge de travail ou l’étendue change.
Scope	Périmètre	La limite ou l’extension jusqu’à laquelle un processus, une procédure, une certification, un contrat, etc s’applique. Par exemple, l’étendue de la gestion des changements peut inclure tous les services des TI réels et les éléments de configuration concernés, l’étendue d’un certificat ISO/IEC 20000 peut inclure tous les services des TI délivrés par le centre de données mentionné.
Second-line Support	Support de deuxième niveau	(Exploitation de Services) Le deuxième niveau dans la hiérarchie des groupes d’assistance impliqués dans la résolution des incidents et l’investigation des problèmes.
Second-line Support	Support de deuxième niveau	Chaque niveau présente davantage de compétences spécialisées ou dispose de davantage de temps ou d’autres ressources.
Security	Sécurité	Voir Gestion de la Sécurité de l’Information (ISM).
Security Management	Gestion de la Sécurité	Synonyme de Gestion de la Sécurité de l’Information.
Security Policy	Politique de sécurité	Synonyme de Politique de la Sécurité de l’Information.
Separation of Concerns (SoC)	Séparation des préoccupations (SoC)	(Stratégie de Services) Une approche, pour concevoir une solution ou un service des TI, qui divise le problème en morceaux pouvant être résolus indépendamment. Cette approche sépare le “quoi” du “comment”.
Server	Serveur	(Exploitation de Services) Un ordinateur connecté à un réseau qui fournit des fonctions logicielles utilisées par d’autres ordinateurs.
Service	Service	Un moyen de fournir une valeur à des clients en facilitant les aboutissements que les clients veulent obtenir sans avoir la propriété des coûts ou des risques spécifiques.
Service Acceptance Criteria (SAC)	Critères d’acceptation d’un service (SAC)	(Transition de Services) Un ensemble de critères permettant d’assurer qu’un service des TI correspond à sa fonctionnalité et aux exigences de qualité et que le fournisseur de service des TI est prêt à faire fonctionner ce nouveau service des TI dès qu’il aura été déployé.
Service Acceptance Criteria (SAC)	Critères d’acceptation d’un service (SAC)	Voir Acceptation.
Service Analytics	Analytique de services	(Stratégie de Services) Technique servant à évaluer l’impact des incidents sur le business. Les analytiques de service modélisent les interdépendances entre les divers éléments de configuration, et les dépendances des services des TI envers les éléments de configuration.
Service Asset	Actif de service (service asset)	Toute capacité ou ressource d’un fournisseur de service.
Service Asset	Actif de service (service asset)	Voir Actif.
Service Asset and Configuration Management (SACM)	Gestion des Actifs de Services et des Configurations (SCAM)	(Transition de Services) Processus en charge à la fois de la gestion des configurations et de la gestion des actifs.
Service Capacity Management (SCM)	Gestion de la Capacité des Services (SCM)	(Conception de services) (Amélioration continuelle du service) Activité en charge de la compréhension des performances et de la capacité des services des TI. Les ressources utilisées par chaque service des TI et le schéma d’utilisation dans le temps sont collectés, enregistrés et analysés afin de servir à l’élaboration d’un plan de capacité.
Service Capacity Management (SCM)	Gestion de la Capacité des Services (SCM)	Voir Gestion de la capacité business (BCM), Gestion de la capacité du composant (CCM).
Service Catalogue	Catalogue des services	(Conception de services) Une base de données ou un document structuré comportant des informations sur tous les services des TI réels, dont ceux qui sont disponibles pour leur déploiement. Le catalogue des services est la seule partie du portefeuille des services rendue publique aux clients, et sert de support de vente et de fourniture des services des TI. Le catalogue des services comprend des informations sur les livrables, les prix, les points de contact, les processus de commande et de demande.
Service Catalogue	Catalogue des services	Voir Portefeuille des contrats.
Service Continuity Management	Gestion de la Continuité des Services	Synonyme de Gestion de la continuité des services
Service Continuity Management	Gestion de la Continuité des Services	des TI (ITSCM).
Service Contract	Contrat de service	(Stratégie de Services) Un contrat pour fournir un ou plusieurs services des TI. Le terme “Contrat de service” signifie également tout accord pour fournir des services des TI, que ce soit un contrat légal ou un SLA.
Service Contract	Contrat de service	Voir Portefeuille des contrats.
Service Culture	Culture de service	Un culture orientée client. Les objectifs majeurs d’une culture du service sont la satisfaction du client et aider le client à atteindre ses objectifs métier .
Service Design	Conception de Services	(Conception de services) Une phase du cycle de vie d’un service des TI. La conception d’un service comporte un certain nombre de processus et de fonctions, c’est le titre d’une des publications phares de l’ITIL.
Service Design	Conception de Services	Voir Conception.
Service Design Package (SDP)	Package de conception de service (SDP)	(Conception de services) Un ou plusieurs document(s) définissant tous les aspects d’un service des TI et ses exigences à toutes les étapes de son cycle de vie. Un package de conception de service est produit à chaque nouveau service des TI, changement majeur ou suppression d’un service des TI.
Service Desk	Centre de Services	(Exploitation de Services) Le point de contact unique entre le fournisseur de service et les utilisateurs. Un centre de services typique gère les incidents et les demandes de service, ainsi que les communications avec les utilisateurs.
Service Failure Analysis (SFA)	Analyse des défaillances de service (SFA)	(Conception de services) Activité qui a pour raison d’identifier les causes sous-jacentes d’une ou plusieurs interruptions du service des TI. La SFA identifie également les opportunités d’amélioration des processus et des outils du fournisseur de service des TI et pas seulement celles de l’infrastructure des TI. La SFA est une activité de type projet avec des contraintes de temps, plutôt qu’un processus d’analyse courant.
Service Failure Analysis (SFA)	Analyse des défaillances de service (SFA)	Voir Analyse de la cause fondamentale (RCA).
Service Hours	Heures de service	(Conception de services) (Amélioration continuelle du service) Une période convenue pendant laquelle un service des TI spécifique doit être disponible. Par exemple, “Lundi-Vendredi de 8h00 à 17h00 sauf jours fériés” Les heures de service doivent être définies dans un accord sur les niveaux de service (SLA).
Service Improvement Plan (SIP)	Plan d’amélioration des services (SIP)	(Amélioration continuelle du service) Un plan formel de mise en œuvre d’améliorations d’un processus ou d’un service des TI.
Service Knowledge Management System (SKMS)	Système de Gestion des Connaisances des Services (SKMS)	(Transition de Services) Un ensemble d’outils et de bases de données servant à gérer les connaissances et les informations. Le SKMS inclut le système de gestion des configurations, ainsi que d’autres outils et bases de données. Le SKMS stocke, gère, tient à jour et présente toutes les informations dont un fournisseur de service des TI a besoin pour gérer le cycle de vie complet des services des TI.
Service Level	Niveau de service	Réalisation mesurée et rapportée d’une ou plusieurs cibles de niveau de service. Le terme “Niveau de service” est parfois utilisé de façon informelle pour signifier cible de niveau de service.
Service Level Agreement (SLA)	Accord sur les niveaux de service (SLA)	(Conception de services) (Amélioration continuelle du service) Un accord entre un fournisseur de service des TI et un client. Le SLA décrit le service des TI, documente les cibles de niveau de service et spécifie les responsabilités du fournisseur de service des TI et du client. Un seul SLA peut couvrir plusieurs services des TI ou plusieurs clients.
Service Level Agreement (SLA)	Accord sur les niveaux de service (SLA)	Voir Accord sur les niveaux opérationnels (OLA).
Service Level Management (SLM)	Gestion des Niveaux de Service (SLM)	(Conception de services) (Amélioration continuelle du service) Processus en charge de négocier les accords sur les niveaux de service (SLA) et de s’assurer qu’ils sont atteints . La SLM doit s’assurer également que tous les processus de gestion des services des TI, les accords sur les niveaux opérationnels (OLA) et les contrats de sous-traitance sont adaptés aux cibles de niveau de service. La SLM surveille et établit des rapports sur les niveaux de service, et organise régulièrement des revues avec les clients.
Service Level Package (SLP)	Package des niveaux de service (SLP)	(Stratégie de Services) Un niveau défini d’utilité et de garantie pour un Package de services particulier. Chaque SLP est conçu pour satisfaire les besoins d’un schéma d’activité business (PBA) particulier.
Service Level Package (SLP)	Package des niveaux de service (SLP)	Voir Ligne de service (LOS).
Service Level Requirement (SLR)	Exigence de niveau de service (SLR)	(Conception de services) (Amélioration continuelle du service) Une exigence du client pour un aspect particulier d’un service des TI. Les SLR sont basés sur les objectifs business et servent à négocier les cibles de niveau de service convenues.
Service Level Target	Cible de niveau de service (Service Level Target)	(Conception de services) (Amélioration continuelle du service) Un engagement documenté par un accord sur les niveaux de service (SLA). Les cibles de niveau de service sont basées sur les exigences de niveau de service (SLR) et doivent assurer que la conception d’un service des TI est adaptée aux besoins. Les cibles de niveau de service doivent être SMART et sont habituellement basées sur les KPI.
Service Maintenance Objective (SMO)	Objectif de maintenance des services (SMO)	(Exploitation de Services) Le temps estimé pendant lequel un élément de configuration sera indisponible du fait de l’activité de maintenance planifiée.
Service Management	Gestion des Services	La gestion du/des service(s) est un ensemble de possibilités organisationnelles spécialisées destinées à fournir une valeur aux clients sous la forme de service(s).
Service Management Lifecyle	Cycle de vie de la gestion du (des) service(s)	Une approche de la gestion des services des TI qui met l’accent sur l’importance de la coordination et des contrôles pendant les diverses fonctions, processus et systèmes nécessaires pour gérer le cycle de vie complet des services des TI. Le cycle de vie de la gestion du/des service(s) est une approche qui prend en compte la stratégie, la conception, la transition, l’exploitation et l’amélioration des services des TI.
Service Manager	Gestionnaire de Services	Un gestionnaire qui est responsable de la gestion quotidienne du cycle de vie d’un ou plusieurs services des TI. Le terme “ Gestionnaire du/des service(s)” sert aussi à désigner tout gestionnaire au sein du fournisseur de services des TI. Communément utilisé pour désigner un gestionnaire des relations business, un gestionnaire de processus, un directeur comptable, ou un dirigeant ayant des responsabilités sur l’ensemble des services des TI.
Service Operation	Exploitation de Services	(Exploitation de Services) Une étape du cycle de vie d’un service des TI. L’Exploitation de Services comporte un certain nombre de processus et de fonctions, c’est également l’intitulé d’une des publications-phares de l’ITIL.
Service Operation	Exploitation de Services	Voir Opération.
Service Owner	Propriétaire de service	(Amélioration continuelle du service) Un rôle qui est responsable de la fourniture d’un service des TI spécifique.
Service Package	Package d’un service	(Stratégie de Services) Une description détaillée d’un service des TI étant disponible pour les clients. Un package de services comprend un package de niveau(x) de service(s) (SLP) ainsi qu’un ou plusieurs services essentiels et des services de soutien.
Service Pipeline	Pipeline des services	(Stratégie de Services) Une base de données ou un document structuré qui établit la liste de tous les services des TI qui sont en considération ou en développement, mais ne sont pas encore disponibles pour les clients. Le pipeline de services fournit une vision business des éventuels services des TI futurs et fait partie du portefeuille de services, qui n’est habituellement pas diffusé aux clients.
Service Portfolio	Portefeuille des services	(Stratégie de Services) L’ensemble complet des services qui sont gérés par un fournisseur de services. Le portefeuille de services sert à gérer le cycle de vie complet de tous les services et comprend trois catégories : Pipeline de services (proposés ou en développement), Catalogue des services (réels ou disponibles pour la mise-en-oeuvre ), et les services supprimés.
Service Portfolio	Portefeuille des services	Voir Gestion du portefeuille de services, Portefeuille de contrats.
Service Portfolio Management (SPM)	Gestion du Portefeuille des Services (SPM)	(Stratégie de Services) Processus en charge de la gestion du portefeuille de services. La gestion du portefeuille de services considère les services de par la valeur métiers qu’ils peuvent fournir.
Service Potential	Potentiel de service	(Stratégie de Services) La valeur totale possible de l’ensemble des capacités et des ressources du fournisseur de services de TI.
Service Provider	Fournisseur de services	(Stratégie de Services) Une organisation qui fournit des services à un ou plusieurs clients internes ou clients externes. Le terme “fournisseur de services” est souvent employé comme synonyme pour Fournisseur de services des TI.
Service Provider	Fournisseur de services	Voir Fournisseur de services de type I, Fournisseur de services de type II, Fournisseur de services de type III.
Service Provider Interface (SPI)	Interface avec le fournisseur de service (SPI)	(Stratégie de Services) Une interface entre le fournisseur de services des TI et un utilisateur, client, processus business ou un sous-traitant. L’analyse des interfaces de fourniture de services aide à coordonner de bout en bout la gestion des services des TI.
Service Provisioning Optimization (SPO)	Optimisation de la fourniture de services (SPO)	(Stratégie de Services) Analyser les finances et les contraintes d’un service des TI afin de décider si des approches différentes de la fourniture du service pourraient réduire les coûts ou améliorer la qualité.
Service Reporting	Reporting des services	(Amélioration continuelle du service) Processus en charge de produire et de fournir des rapports concernant l’obtention et les tendances des niveaux de service. Le processus rapport de service devrait inclure l’accord sur le format, le contenu et la fréquence de diffusion de ces rapports avec les clients
Service Request	Demande de service	(Exploitation de Services) Une demande d’un utilisateur pour avoir une information, un conseil ou pour bénéficier d’un changement standard ou encore pour avoir un accès à un service des TI. Par exemple, pour réinitialiser un mot de passe, ou fournir des services des TI standard à un nouvel utilisateur. Les demandes de service sont habituellement gérées par un centre de services et ne nécessitent pas de RFC pour être soumises.
Service Request	Demande de service	Voir Satisfaction de la demande.
Service Sourcing	Sourcing de services	(Stratégie de Services) Stratégie et approche pour décider si un service sera fourni en interne ou pour l’externaliser en employant un fournisseur externe. L’approvisionnement en service signifie également l’exécution de cette stratégie, ce qui inclut :
		• Approvisionnement interne – Services partagés ou internes utilisant des fournisseurs de services de type I ou de type II.
		• Approvisionnement traditionnel – Externalisation complète du service en employant un fournisseur de services de type III.
		• Approvisionnement multidistributeurs – Externalisation majeure, consortium ou sélective employant des fournisseurs de services de type III.
Service Strategy	Stratégie de Services	(Stratégie de Services) Le titre d’une des publications phares de l’ITIL. La stratégie de service établit une stratégie globale pour les services des TI et pour la gestion des services des TI.
Service Transition	Transition de Services	(Transition de Services) Une étape du cycle de vie d’un service des TI. La transition de service inclut un certain nombre de processus et de fonctions et c’est aussi le titre d’une des publications phares de l’ITIL.
Service Transition	Transition de Services	Voir Transition.
Service Utility	Utilité du service	(Stratégie de Services) La fonctionnalité d’un service des TI du point de vue du client. La valeur business d’un service des TI est générée par la combinaison de l’utilité de ce service (ce qu’il fait) et la garantie du service (comment il y parvient).
Service Utility	Utilité du service	Voir Utilité.
Service Validation and Testing	Validation et Tests de Services	(Transition de Services) Processus en charge de la validation et du test d’un service des TI, nouveau ou changé. La validation et le test assurent que le service des TI correspond à ses caractéristiques de conception et qu’il répondra aux besoins du business.
Service Valuation	Estimation de la valeur du service	(Stratégie de Services) Une mesure du coût total de la fourniture d’un service des TI et la valeur totale pour le business de ce service des TI. L’évaluation du service permet d’aider le business et le fournisseur de services des TI à convenir de la valeur du service des TI.
Service Warranty	Garantie de service	(Stratégie de Services) L’assurance qu’un service des TI satisfera les exigences convenues. Il peut s’agir d’un accord formel, tel qu’un accord sur les niveaux de service (SLA) ou d’un contrat, ou bien ce peut être un message marketing ou une image de marque. La valeur business d’un service des TI est générée par la combinaison de l’utilité du service (ce qu’il fait) et la garantie du service (comment il y parvient).
Service Warranty	Garantie de service	Voir Garantie.
Serviceability	Serviçabilité	(Conception de services) (Amélioration continuelle du service) La capacité d’un sous-traitant tiers à satisfaire aux termes de son contrat. Ce contrat doit inclure les niveaux convenus de fiabilité, de facilité de maintenance et de disponibilité d’un élément de configuration.
Shift	Équipe	(Exploitation de Services) Un groupe ou une équipe devant exécuter un rôle spécifique pendant une période donnée. Par exemple, il peut y avoir quatre postes de personnel de contrôle de l’exploitation des TI pour soutenir un service des TI qui est utilisé 24 heures sur 24.
Simulation modelling	Modélisation par simulation	(Conception de services) (Amélioration continuelle du service) Technique ayant pour but de créer un modèle détaillé afin de prédire le comportement d’un élément de configuration ou d’un service des TI. Les modélisations de simulation peuvent s’avérer très précises mais sont aussi onéreuses et longues à développer. Une modélisation de simulation est souvent créée à l’aide d’éléments de configuration réels pouvant être modélisés, mais avec des charges de travail et des transactions artificielles. Elles sont utilisées dans la gestion de la capacité lorsque des résultats précis sont indispensables. Un modèle de simulation est parfois appelé Test de performance.
Single Point of Contact (SPOC)	Point de contact unique (SPOC)	(Exploitation de Services) Fournit un moyen unique et cohérent de communiquer avec une organisation ou une unité métiers. Par exemple, le point de contact unique d’un fournisseur de services des TI est habituellement appelé Centre de services.
Single Point of Failure (SPOF)	Point de défaillance unique (SPOF)	(Conception de services) Tout élément de configuration pouvant causer un incident lorsqu’il tombe en panne, et pour lequel une contre-mesure n’a pas été implantée. Un SPOF peut tout aussi bien être une personne, ou une étape d’un processus ou d’une activité, qu’un composant d’une infrastructure des TI.
Single Point of Failure (SPOF)	Point de défaillance unique (SPOF)	Voir Défaillance.
SLAM Chart	Tableau SLAM	(Amélioration continuelle du service) Une charte de surveillance des niveaux de service convenus (Service Level Agreement Monitoring Chart) contribue à la surveillance de ceux-ci et à l’établissement de rapports sur l’obtention des cibles de niveau de service. Une charte SLAM utilise habituellement un code couleur pour montrer si chacune des cibles de niveau de service convenue a été atteinte, manquée ou presque atteinte au cours de chacun des douze derniers mois.
SMART	SMART	(Conception de services) (Amélioration continuelle du service) Acronyme pour aider à se souvenir que les cibles des accords sur les niveaux de service et des plans de projet doivent être Spécifiques, Mesurables, Atteignables, en Rapport (Relevant) et Temporellement opportunes (Timely).
Snapshot	Instantané	(Transition de Services) L’état actuel d’une configuration tel qu’il a été saisi par un outil de découverte.
		Également employé comme synonyme de Test de performance.
		Voir Base de référence.
Source	Source	Voir Approvisionnement en service.
Specification	Spécification	Une définition formelle des exigences. Une spécification peut servir à définir des exigences opérationnelles ou techniques, et peut être interne ou externe. De nombreux standards publics sont composés d’un code de pratique et d’une spécification. La spécification définit le standard par rapport auquel une organisation peut être soumise à un audit.
Stakeholder	Partie prenante	Toutes les personnes qui ont un intérêt dans une organisation, un projet, un service des TI etc. Les intervenants peuvent être intéressés par les activités, les cibles, les ressources ou les biens délivrés. Les intervenants peuvent être des clients, des partenaires, des employés, des actionnaires, des propriétaires, etc.
Stakeholder	Partie prenante	Voir RACI.
Standard	Standard	Une exigence obligatoire. Exemples : ISO/IEC 20000 (une norme internationale), une norme de sécurité interne pour une configuration Unix, ou un standard gouvernemental sur la manière de tenir à jour les enregistrements financiers. Le terme “standard” fait aussi référence à un code de pratique ou à une spécification publiée par un Organisme de Standards telle que ISO ou BSI.
Standard	Standard	Voir Principe.
Standard change	Changement standard	(Transition de Services) Un changement pré-approuvé présentant peu de risque, relativement commun et qui sera exécuté selon une procédure ou une instruction de travail. Par exemple, la réinitialisation d’un mot de passe ou la fourniture d’un équipement standard à nouvel employé. Des RFC ne sont pas requises pour implanter un changement standard, RFC qui sont journalisées et suivies selon un mécanisme différent, tel qu’une demande de service.
Standard change	Changement standard	Voir Modèle de changement.
Standard Operating Procedures (SOP)	Procédures standard d’exploitation (SOP)	(Exploitation de Services) Procédures utilisées par la Gestion de l’exploitation des TI.
Standby	De secours	(Conception de services) Fait référence aux ressources qui ne sont pas nécessaires à la fourniture des services des TI réels, mais sont disponibles pour soutenir les plans de continuité des services des TI. Par exemple, un centre de données de secours peut être tenu à jour afin de soutenir des arrangements de Reprise immédiate ou rapide, Reprise intermédiaire ou Reprise graduelle.
Statement of requirements (SOR)	Relevé des besoins (SQR)	(Conception de services) Document contenant toutes les exigences pour l’achat d’un produit, un service des TI nouveau ou changé.
Statement of requirements (SOR)	Relevé des besoins (SQR)	Voir Termes de référence.
Status	Statut	Le nom d’un champ obligatoire dans de nombreux types d’enregistrements. Il indique l’état actuel dans le cycle de vie de l’élément de configuration, l’incident, le problème associé.
Status accounting	Gestion des Statuts	(Transition de Services) Activité en charge de l’enregistrement et du rapport du cycle de vie de chaque élément de configuration.
Storage Management	Gestion du stockage	(Exploitation de Services) Processus en charge de la gestion du stockage et de la maintenance des données tout au long de leur cycle de vie.
Strategic	Stratégique	(Stratégie de Services) Le plus haut des trois niveaux de planification et de fourniture (Stratégique, Tactique, Opérationnel). Les activités stratégiques incluent la définition des objectifs et la planification à long terme pour avoir une vision globale.
Strategy	Stratégie	(Stratégie de Services) Un plan stratégique établi pour atteindre les objectifs définis.
Super User	Superutilisateur	(Exploitation de Services) Un utilisateur qui aide d’autres utilisateurs et les assiste dans leur communication avec le centre de services ou d’autres parties du fournisseur de service des TI. Les super utilisateurs fournissent habituellement une assistance aux incidents mineurs et à la formation.
Supplier	Fournisseur	(Stratégie de Services) (Conception de services) Une tierce partie responsable de la fourniture de biens ou de services qui sont nécessaires à la fourniture de services des TI. Exemples de sous-traitants : revendeurs de matériel et de logiciels, fournisseurs de réseau et de télécoms et organisations d’externalisation.
Supplier	Fournisseur	Voir Contrat de sous-traitance, Chaîne de sous-traitance.
Supplier and Contract Database (SCD)	Base de donnée des fournisseurs et des contrats (SCD)	(Conception de services) Une base de données ou un document structuré servant à gérer les contrats de sous-traitance tout au long de leur cycle de vie. La SCD contient les attributs clés de tous les contrats avec les sous-traitants et doit faire partie du Système de gestion des connaissances du service (SKMS).
Supplier Management	Gestion des Fournisseurs	(Conception de services) Processus en charge de s’assurer que tous les contrats avec les sous-traitants soutiennent les besoins du business et que tous les sous-traitants remplissent leurs engagements contractuels.
Supply Chain	Chaîne d’approvisionnement	(Stratégie de Services) Les activités d’une chaîne de valeur exécutées par des sous-traitants. Une chaîne de sous-traitance implique de multiples sous-traitants, chacun ajoutant de la valeur au produit ou au service.
Supply Chain	Chaîne d’approvisionnement	Voir Réseau de valeur.
Support Group	Groupe de support	(Exploitation de Services) Un groupe de personnes ayant des compétences techniques. Les groupes d’assistance fournissent l’assistance technique réclamée par l’ensemble des processus de gestion des services des TI.
Support Group	Groupe de support	Voir Gestion technique.
Support Hours	Heures de support	(Conception de services) (Exploitation de Services) Les heures auxquelles l’assistance est disponible pour les utilisateurs. Normalement ce sont les horaires d’ouverture du Centre de services. L’horaire d’assistance doit être défini dans un accord sur les niveaux de service (SLA) et peut être différent des heures de service. Par exemple, les heures de service peuvent être 24h/24 et l’horaire d’assistance sera 7h00 à 19h00.
Supporting Service	Service de soutien	(Stratégie de Services) Un service qui active ou améliore un service essentiel. Par exemple un service d’annuaire ou un service de copie de sauvegarde.
Supporting Service	Service de soutien	Voir Package de services.
SWOT Analysis	Analyse SWOT	(Amélioration continuelle du service) Une technique qui revoit et analyse les forces et les faiblesses internes d’une organisation, ainsi que les opportunités et les menaces extérieures auxquelles elle doit faire face. SWOT signifie Forces (Strengths), Faiblesses (Weakness), Opportunités (Opportunity) et Menaces (Threats).
System	Système	Un certain nombre de choses reliées entre elles, fonctionnant en réseau pour atteindre un objectif global. Par exemple :
		• Un système informatique incluant matériel, logiciels et applications.
		• Un système de gestion, incluant de multiples processus qui sont planifiés et gérés ensemble. Par exemple, un système de gestion de la qualité.
		• Un système de gestion de base de données ou un système d’exploitation qui comprend plusieurs modules logiciels conçus pour exécuter un ensemble de fonctions associées.
System Management	Gestion des Systèmes	La partie de la gestion des services des TI qui s’intéresse davantage à la gestion de l’infrastructure des TI qu’aux processus.
Tactical	Tactique	(Stratégie de Services) Le niveau intermédiaire des trois niveaux de planification et de fourniture (Stratégique, Tactique, Opérationnel). Les activités tactiques incluent les plans à moyen terme nécessaire pour atteindre des objectifs spécifiques, habituellement sur une période de quelques semaines ou quelques mois.
Tag	Étiquette (tag)	(Stratégie de Services) Un code court servant à identifier une catégorie. Par exemple les tags EC1, EC2, EC3, etc peuvent servir à identifier différents résultats des clients lors de l’analyse et de la comparaison des stratégies. Le terme Marquage fait aussi référence à l’activité de marquer des objets.
Technical Management	Gestion technique	(Exploitation de Services) Fonction en charge de fournir des compétences techniques pour assister les services des TI et la gestion de l’infrastructure des TI. La gestion technique définit les rôles des groupes d’assistance, ainsi que les outils, processus et procédures nécessaires.
Technical Observation (TO)	Observation technique (TO)	(Amélioration continuelle du service) Technique servant à l’amélioration du service, l’investigation des problèmes et la gestion de la disponibilité. L’équipe d’assistance technique doit surveiller le comportement et les performances d’un service des TI et faire des recommandations pour son amélioration.
Technical Service	Service technique	Synonyme de Service d’infrastructure.
Technical Support	Support technique	Synonyme de Gestion technique.
Tension Metrics	Mesures en tension	(Amélioration continuelle du service) Un ensemble de mesures associées, dans lesquelles les améliorations d’une des mesures ont un effet négatif sur une autre. Les mesures de tensions ont été conçues pour assurer qu’un équilibre adéquat est obtenu.
Terms of Reference (TOR)	Termes de référence (TOR)	(Conception de services) Document spécifiant les exigences, l’étendue, les biens à délivrer, les ressources et le calendrier d’un projet ou d’une activité.
Test	Test	(Transition de Services) Activité ayant pour but de vérifier qu’un élément de configuration, un service des TI, un processus, etc correspond à ses spécifications ou aux exigences convenues.
Test	Test	Voir Validation et test du service, Acceptation.
Test Environment	Environnement de tests	(Transition de Services) Un environnement sous contrôle servant à tester des éléments de configuration, des constructions, des services des TI, des processus, etc.
Third Party	Tierce partie	Une personne, un groupe ou un business qui ne fait pas partie de l’accord sur les niveaux de service d’un service des TI, mais est nécessaire pour assurer la fourniture réussie de ce service des TI. Par exemple un fournisseur de logiciels sous-traitant, une société de maintenance de matériel ou un département de l’équipement. Les exigences envers les tierces parties sont habituellement stipulées dans des contrats de sous-traitance ou des accords sur les niveaux opérationnels (OLA).
Third-line Support	Support de troisième niveau	(Exploitation de Services) Le troisième niveau dans la hiérarchie des groupes d’assistance impliqués dans la résolution des incidents et l’investigation des problèmes.
Third-line Support	Support de troisième niveau	Chaque niveau contient davantage de compétences spécialisées ou dispose de davantage de temps ou d’autres ressources.
Threat	Menace	Tout ce qui peut exploiter la vulnérabilité. Toute cause potentielle d’incident peut être considérée comme une menace. Par exemple, un incendie est une menace pouvant exploiter la vulnérabilité des revêtements de sol inflammables. Ce terme est communément utilisé par la Gestion de la Sécurité de l’Information (ISM) et la Gestion de la continuité du service des TI (ITSCM), mais s’applique aussi à d’autres domaines tels que la gestion des problèmes et la gestion de la disponibilité.
Threshold	Seuil	Valeur d’une mesure qui pourrait provoquer le déclenchement d’une alerte ou la mise en place d’une action de gestion. Par exemple “Incident de Priorité1 non résolu en 4 heures”, “plus de 5 erreurs disque en une heure” ou “plus de 10 échecs de changement en un mois”.
Throughput	Capacité de traitement	(Conception de services) Une mesure du nombre de transactions ou autres opérations effectuées dans un délai donné. Par exemple, 5000 e-mails envoyés par heure ou 200 accès disque par seconde.
Total Cost of Ownership (TCO)	Coût total de possession (TCO)	(Stratégie de Services) Une méthodologie qui aide à la prise de décision en termes d’investissement. Le TCO évalue l’ensemble du coût de la possession tout au long du cycle de vie d’un élément de configuration, pas seulement le coût initial ou son prix d’achat.
Total Cost of Ownership (TCO)	Coût total de possession (TCO)	Voir Coût total d’utilisation.
Total Cost of Utilization (TCU)	Coût total d’utilisation (TCU)	(Stratégie de Services) Une méthodologie qui aide à la prise de décision en termes d’investissement et d’approvisionnement en service. Le TCU évalue l’ensemble du coût pour le client du cycle de vie d’un service des TI.
Total Cost of Utilization (TCU)	Coût total d’utilisation (TCU)	Voir Coût total de possession.
Total Quality Management (TQM)	Gestion par la qualité totale (TQM)	(Amélioration continuelle du service) Une méthodologie pour gérer l’amélioration continuelle à l’aide d’un système de gestion de la qualité. La TQM établit une culture impliquant toutes les personnes de l’organisation dans un processus de surveillance et d’amélioration continues.
Transaction	Transaction	Une fonction séparée exécutée par un service des TI. Par exemple, transférer de l’argent d’un compte bancaire à un autre. Une seule transaction peut impliquer de nombreux ajouts, suppressions et modifications de données. Soit elles réussissent toutes, soit aucune d’entre elles n’est prise en compte.
Transition	Transition	(Transition de Services) Un changement d’état, correspondant à un mouvement d’un service des TI ou autre élément de configuration d’une étape de son cycle de vie vers la suivante.
Transition Planning and Support	Planification et Support à la Transition	(Transition de Services) Processus en charge de planifier tous les processus de transition de service et de coordonner les ressources qui leur sont nécessaires. Ces processus de transition de service sont la Gestion des changements, la Gestion des actifs et des configurations de service (SACM), la Validation et les tests du service, l’Évaluation, et la Gestion des connaissances.
Trend Analysis	Analyse de tendance	(Amélioration continuelle du service) Analyse des données permettant d’identifier des schémas relatifs au temps. L’analyse des tendances est employée par la Gestion des problèmes afin d’identifier les défaillances habituelles ou les éléments de configuration fragiles, et par la Gestion de la capacité comme outil de modélisation pour prédire un futur comportement. Elle est aussi utilisée comme outil de gestion pour identifier les déficiences dans les processus de gestion des services des TI.
Tuning	Réglage (tuning)	Activité en charge de la planification des changements afin d’avoir un usage efficace des ressources. Le réglage fait partie de la gestion des performances, qui inclut aussi la surveillance des performances et l’implantation des changements requis.
Type I Service Provider	Fournisseur de services de type I	(Stratégie de Services) Un fournisseur de services interne qui est imbriqué dans une unité business. Il peut y avoir plusieurs fournisseurs de services de type I au sein d’une organisation.
Type II Service Provider	Fournisseur de services de type II	(Stratégie de Services) Un fournisseur de services interne qui fournit des services des TI partagés par plusieurs unités business.
Type III Service Provider	Fournisseur de services de type III	(Stratégie de Services) Un fournisseur de services qui fournit des services des TI à des clients externes.
Underpinning Contract (UC)	Contrat de sous-traitance (UC)	(Conception de services) Un contrat passé entre un fournisseur de services des TI et une tierce partie. La tierce partie fournit des biens ou des services qui soutiennent la fourniture d’un service des TI à un client. Le contrat de sous-traitance définit les cibles et les responsabilités qui sont nécessaires pour atteindre les cibles de niveau de service convenues d’un SLA.
Unit Cost	Coût unitaire	(Stratégie de Services) Le coût pour le fournisseur de services des TI de la fourniture d’un composant unitaire d’un service des TI. Par exemple, le coût d’un ordinateur de bureau ou d’une transaction.
Urgency	Urgence	(Transition de Services) (Conception de services) Mesure du temps que met un incident, un problème ou un changement à avoir un impact significatif sur les métiers. Par exemple, un incident à fort impact peut avoir une urgence faible, si cet impact n’affecte pas le business avant la fin de l’année fiscale. Impact et urgence servent à attribuer un niveau de priorité.
Usability	Facilité d’utilisation	(Conception de services) La facilité avec laquelle une application, un produit ou un service des TI peut être utilisé. Les exigences de facilité d’emploi sont souvent incluses dans l’énoncé des exigences.
Use Case	Scénario d’utilisation	(Conception de services) Technique utilisée pour définir la fonctionnalité requise et les objectifs, et pour la conception de tests. Les études de cas définissent des scénarios réalistes décrivant les interactions entre les utilisateurs et un service des TI ou un autre système.
Use Case	Scénario d’utilisation	Voir Étude de changement.
User	Utilisateur	Une personne qui utilise quotidiennement un service des TI. Les utilisateurs se distinguent des clients, car certains clients n’utilisent pas directement le service des TI.
User Profile (UP)	Profil d’utilisateur (UP)	(Stratégie de Services) Schéma des demandes des utilisateurs envers les services des TI. Chaque profil utilisateur comporte un ou plusieurs schémas d’activité business (PBA).
Utility	Utilité	(Stratégie de Services) Fonctionnalité offerte par un produit ou un service des TI pour satisfaire un besoin particulier. L’utilité est souvent résumée par “à quoi ça sert”.
Utility	Utilité	Voir Utilité du service.
Validation	Validation	(Transition de Services) Activité assurant qu’un service des TI, processus, plan ou autre livrable, nouveau ou changé correspond aux besoins du business. La validation assure que les exigences du business sont satisfaites même si celles-ci ont changé depuis la conception d’origine.
Validation	Validation	Voir Vérification, Acceptation, Qualification, Validation et test du service.
Value Chain	Chaîne de valeur	(Stratégie de Services) Une suite de processus qui crée un produit ou un service des TI ayant une valeur pour un client. Chaque étape de la séquence se construit sur les précédentes et contribue à l’ensemble du produit ou du service.
Value Chain	Chaîne de valeur	Voir Réseau de valeur.
Value for money	Rentabilité (Value for money)	Une mesure informelle de la rentabilité. Le rapport qualité/prix est souvent basé sur la comparaison des coûts des solutions alternatives.
Value for money	Rentabilité (Value for money)	Voir Analyse des coûts et des bénéfices.
Value Network	Réseau de création de valeur	(Stratégie de Services) Un ensemble complexe de relations entre deux groupes ou organisations, voire plus. La valeur est générée grâce aux échanges de compétences, d’informations, de biens ou de services.
Value Network	Réseau de création de valeur	Voir Chaîne de valeur, Partenariat.
Value on Investsment (VOI)	Valeur sur investissement (VOI)	(Amélioration continuelle du service) Une mesure du bénéfice escompté d’un investissement. La VOI prend en compte à la fois les bénéfices financiers et les bénéfices tangibles.
Value on Investsment (VOI)	Valeur sur investissement (VOI)	Voir Retour sur investissement.
Variable Cost Dynamic	Coût variable	(Stratégie de Services) Un coût dépendant de la manière dont un service des TI est utilisé, du nombre de produits fabriqués, du nombre et du type d’utilisateurs, ou de quoique ce soit d’autre ne pouvant pas être fixé à l’avance.
Variable Cost Dynamic	Coût variable	Voir Dynamique des coûts variables.
Variable Cost Dynamic	Dynamique des coûts variables	(Stratégie de Services) Technique servant à comprendre comment des coûts globaux sont influencés par les nombreux éléments variables complexes qui contribuent à la fourniture de services des TI.
Variance	Variance	La différence entre la valeur prévue et la valeur réelle mesurée. Souvent utilisée par la Gestion financière, la Gestion de la capacité et la Gestion des niveaux de service, mais pourrait s’appliquer dans de nombreux domaines où des plans sont mis en place.
Verification	Vérification	(Transition de Services) Activité s’assurant qu’un service des TI, processus, plan ou autre livrable, nouveau ou changé est complet, précis, fiable et correspond à ses caractéristiques de conception.
Verification	Vérification	Voir Validation, Acceptation, Validation et test du service.
Verification and Audit	Vérification et audit	(Transition de Services) Activités en chargent d’assurer que les informations contenues dans la CMDB sont précises et que tous les éléments de configuration ont été identifiés et enregistrés dans celle-ci. La vérification inclut les vérifications de routine qui font partie des autres processus. Par exemple, vérifier le numéro de série d’un ordinateur lorsqu’un utilisateur saisit un incident. L’audit est une vérification périodique formelle.
Version	Version	(Transition de Services) Une version sert à identifier la base de référence spécifique d’un élément de configuration. Habituellement, les versions utilisent une convention pour l’attribution de leur nom permettant de définir une séquence ou de dater chacune des bases de référence. Par exemple, l’application de Paye Version 3 contient une fonctionnalité mise à jour depuis la version 2.
Vision	Vision	Description de ce qu’une organisation souhaite devenir dans le futur. Une vision est générée par la direction et sert à influencer la culture et la planification stratégique.
Vital Business Function (VBF)	Fonction Business Vitale (VBF)	(Conception de services) Une fonction d’un processus métiers qui est cruciale pour le succès des métiers. Les fonctions métiers vitales sont d’une importance considérable pour la Gestion de la continuité des métiers, la Gestion de la continuité des services des TI, la Gestion de la disponibilité.
Vulnerability	Vulnérabilité	Une faiblesse qui pourrait être exploitée par une menace. Par exemple, un pare-feu ouvert, un mot de passe qui n’est jamais changé ou une moquette inflammable. Un contrôle manquant est également considéré comme une vulnérabilité.
Warm Standby	Warm Standy ou Reprise à chand	Équivalent de Immediate Recovey (Reprise immédiate).
Warranty	Garantie	(Stratégie de Services) Une promesse ou une garantie qu’un produit ou un service répond à ses exigences convenues.
Warranty	Garantie	Voir Validation et test du service, Garantie du service.
Work in Progress (WIP)	Travail en cours (WIP)	Un état signifiant que des activités ont commencé mais ne sont pas encore terminées. Communément employé comme un état pour les incidents, les problèmes, les changements, etc.
Work Instruction	Instruction de travail	Document contenant des instructions détaillées qui spécifient exactement quelles sont les étapes à effectuer pour mener à bien une activité. Une instruction de travail contient beaucoup de détails qu’une procédure et n’est créée que si des instructions très détaillées sont nécessaires.
Workaround	Solution de contournement	(Exploitation de Services) Réduire ou éliminer l’impact d’un incident ou d’un problème pour lequel une résolution complète n’est pas encore disponible. Par exemple, en redémarrant un élément de configuration défaillant. Les solutions de contournement des problèmes sont documentées dans les enregistrements d’erreurs connues. Les solutions de contournement des incidents qui n’ont pas été associées aux enregistrements des problèmes sont documentées dans les enregistrements d’incidents.
Workload	Charge de travail	Les ressources nécessaires pour délivrer une partie identifiable d’un service des TI. Les charges de travail peuvent être classées par catégorie, selon leurs utilisateurs, groupes d’utilisateurs ou leurs fonctions au sein d’un service des TI. Cela sert à assister l’analyse et la gestion de la capacité, les performances, l’utilisation des éléments de configuration et des services des TI. Le terme “charge de travail” est parfois utilisé comme un synonyme de “débit”.

Liste des acronymes

Acronyme	Terme anglais	Terme français
ACD	Automatic Call Distribution	Distribution automatique des appels
AM	Availability Management	Gestion de la disponibilité
AMIS	Availability Management Information System	Système d’informations pour la gestion de la disponibilité
ASP	Application Service Provider	Fournisseur de service logiciel
BCM	Business Capacity Management	Gestion de la capacité des métiers
BCM	Business Continuity Management	Gestion de la continuité des métiers
BCP	Business Continuity Plan	Plan de continuité des métiers
BIA	Business Impact Analysis	Analyse d’impact sur les métiers
BRM	Business Relationship Manager	Gestionnaire des relations avec les métiers
BSI	British Standards Institution	Institution des Standards Britanniques
BSM	Business Service Management	Gestion des services aux métiers
CAB	Change Advisory Board	Comité consultatif des changements
CAB/EC	Change Advisory Board / Emergency Committee	Comité consultatif des changements / Comité d’urgence
CAPEX	Capital Expenditure	Dépenses d’investissement
CCM	Component Capacity Management	Gestion de la capacité du composant
CFIA	Component Failure Impact Analysis	Analyse d’impact de la défaillance d’un composant
CI	Configuration Item	Élément de configuration
CMDB	Configuration Management Database	Base de données de gestion des configurations
CMIS	Capacity Management Information System	Système d’information de la gestion de la capacité
CMM	Capability Maturity Model	Modèle de maturité d’aptitude
CMMI	Capability Maturity Model Integration	Modèles de maturité d’aptitude - intégration
CMS	Configuration Management System	Système de gestion des configurations
COTS	Commercial off the Shelf	Prêt à l’emploi
CSF	Critical Success Factor	Facteur de succès crucial
CSI	Continual Service Improvement	Amélioration continue du service
CSIP	Continual Service Improvement Programme	Programme d’amélioration continue du service
CSP	Core Service Package	Package de services essentiels
CTI	Computer Telephony Integration	Couplage téléphonie-informatique
DIKW	Data-to-Information-to-Knowledge-to-Wisdom	Données –> Information –> Connaissance –> Sagesse
eSCM-CL	eSourcing Capability Model for Client Organizations	eSourcing pour Organisations Clientes
eSCM-SP	eSourcing Capability Model for Service Providers	Modèle d’aptitude à l’eSourcing pour Fournisseurs de Services
FMEA	Failure Modes and Effects Analysis	Analyse des effets et des modes de défaillance
FTA	Fault Tree Analysis	Analyse par arbre de panne
IRR	Internal Rate of Return	Taux de retour interne
ISG	IT Steering Group	Comité de direction des TI
ISM	Information Security Management	Gestion de la Sécurité de l’Information
ISMS	Information Security Management System	Système de Gestion de la Sécurité de l’Information
ISO	International Organization for Standardization	Organisme International de Standardisation
ISP	Internet Service Provider	Fournisseur de services Internet
IT	Information Technology	Technologie de l’information
ITSCM	IT Service Continuity Management	Gestion de la continuité du service des TI
ITSM	IT Service Management	Gestion des services des TI ou Gestion des services informatiques
itSMF	IT Service Management Forum	Forum sur la Gestion des services des TI
IVR	Interactive Voice Response	Réponse vocale interactive
KEDB	Known Error Database	Base de données des erreurs connues
KPI	Key Performance Indicator	Indicateur Clé de Performance
LOS	Line of Service	Ligne de service
MoR	Management of Risk	Gestion du risque
MTBF	Mean Time Between Failures	Intervalle moyen entre les défaillances
MTBSI	Mean Time Between Service Incidents	Intervalle moyen entre les incidents de service
MTRS	Mean Time to Restore Service	Délai moyen de restauration d’un service
MTTR	Mean Time to Repair	Délai moyen de réparation
NPV	Net Present Value	Valeur nette actuelle
OGC	Office of Government Commerce	Chambre de commerce britannique
OLA	Operational Level Agreement	Accord sur les niveaux opérationnels
OPEX	Operational Expenditure	Dépenses de fonctionnement
OPSI	Office of Public Sector Information	Bureau d’Information du Secteur Public
PBA	Pattern of Business Activity	Schéma d’activité business
PFS	Prerequisite for Success	Prérequis du succès
PIR	Post Implementation Review	Revue Post Implantation
PSA	Projected Service Availability	Disponibilité projetée du service
PSO	Projected Service Outage	Interruption projetée du service
QA	Quality Assurance	Assurance Qualité
QMS	Quality Management System	Système de gestion de la qualité
RCA	Root Cause Analysis	Analyse de la cause fondamentale
RFC	Request for Change	Demande de changement
ROI	Return on Investment	Retour sur investissement
RPO	Recovery Point Objective	Objectif de point de reprise
RTO	Recovery Time Objective	Objectif de temps de reprise
SAC	Service Acceptance Criteria	Critère d’acceptation du service
SACM	Service Asset and Configuration Management	Gestion des actifs et des configurations de service
SCD	Supplier and Contract Database	Base de données des sous-traitants et des contrats
SCM	Service Capacity Management	Gestion de la capacité de service
SFA	Service Failure Analysis	Analyse de la défaillance du service
SIP	Service Improvement Plan	Plan d’amélioration du service
SKMS	Service Knowledge Management System	Système de gestion des connaissances du service
SLA	Service Level Agreement	Accord sur les niveaux de service
SLM	Service Level Management	Gestion des niveaux de service
SLP	Service Level Package	Package de niveau de service
SLR	Service Level Requirement	Exigences de niveau de service
SMO	Service Maintenance Objective	Objectif de maintenance du service
SoC	Separation of Concerns	Séparation des intérêts
SOP	Standard Operating Procedures	Procédures d’exploitation standard
SOR	Statement of requirements	Énoncé des exigences
SPI	Service Provider Interface	Interface de fourniture de services
SPM	Service Portfolio Management	Gestion du portefeuille de services
SPO	Service Provisioning Optimization	Optimisation de l’approvisionnement en service
SPOF	Single Point of Failure	Point de défaillance unique
TCO	Total Cost of Ownership	Coût total de possession
TCU	Total Cost of Utilization	Coût total d’utilisation
TO	Technical Observation	Observation technique
TOR	Terms of Reference	Termes de référence
TQM	Total Quality Management	Gestion globale de la qualité
UC	Underpinning Contract	Contrat de sous-traitance
UP	User Profile	Profil utilisateur
VBF	Vital Business Function	Fonction business vitale
VOI	Value on Investment	Valeur sur investissement
WIP	Work in Progress	Travaux en cours

Laisser un commentaire

24 avril 2010

ITPEDIA

Filed under: ITPEDIA — urbandot @ 12 12 36 04364
Tags: itpedia

Bienvenue sur le Blog des Meilleures Pratiques

ITPEDIA-FR.COM

Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

Commentaires Fermés

Prince2 : La méthode de A à Z

Filed under: Uncategorized — urbandot @ 0 12 48 04484

Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

1. Introduction

La plupart des organisations rencontrent des niveaux de changements sans précédents. Le changement est devenu un “mode de vie” pour les entreprises contraintes à maintenir de hauts niveaux de rendement et de compétitivité pour prospérer. Il est désormais essentiel de piloter et d’anticiper les risques inhérents au changement et à l’innovation.

Les projets rassemblent des ressources, des compétences, de la technologie et des idées pour fournir des bénéfices ou atteindre des objectifs business. Une bonne gestion de projet permet de s’assurer que ces bénéfices ou ces objectifs sont atteints au respect du budget, des échéances, et de la qualité attendue.

PRINCE2 est une méthode de gestion de projet conçue pour fournir un framework couvrant la très vaste variété de disciplines et d’activités requises au sein d’un projet. PRINCE2 met le focus sur le cas d’affaire (Business Case), qui expose les justifications fonctionnelles et business à l’origine du projet. Le cas d’affaire guide tous les processus de gestion du projet, depuis la mise au point initiale jusqu’à l’achèvement final.

La description complète de la méthode PRINCE2 est disponible dans l’ouvrage Managing Successful Projects with PRINCE2, publiée par The Stationary Office, et disponible en Français depuis le début de l’année. Cette publication est la traduction non officielle du livre de poche PRINCE2 Pocketbook, rédigé pour servir d’aide-mémoire et de référence pratique à destination des gestionnaires de projets déjà familiarisés avec la méthode et sa terminologie.

2. Les concepts

PRINCE2 est une méthode de gestion de projet adaptée à tous les types de projets. PRINCE2 se concentre sur les aspects de gestion tels que le cas d’affaires, l’organisation du projet, les plans, les contrôles, la qualité et la gestion du risque, qu’elle distingue des tâches spécialisées de fourniture des livrables du projet.

PRINCE2 est une méthode basée sur des processus ce qui permet de moduler les activités de gestion en termes d’échelle, ceci afin de correspondre aux exigences propres à chaque projet.

Tout au long du projet, PRINCE2 incite le chef de projet et le comité de pilotage à se focaliser sur la justification business du projet. Au terme de chaque séquence (stage), le cas d’affaire est révisé pour s’assurer en continu de la viabilité et de la pertinence du projet.

PRINCE2 encourage et soutient l’implication de(s) l’ utilisateur(s), ainsi que de toutes les parties prenantes qui ont un intérêt dans l’aboutissement du projet ou qui peuvent se trouver affectées d’une quelconque façon par son issue.

Un projet PRINCE2 est subdivisé en séquences afin de permettre des évaluations intermédiaires par le comité de pilotage, en vue de la surveillance et du contrôle de sa bonne marche. La fin d’une séquence représente un moment clef pour la prise de décision sur l’engagement à poursuivre ou non le projet. Le nombre de séquences est totalement flexible et est établi sur la base de considérations telles que la taille du projet, sa complexité, les risques inhérents, son importance et donc sa criticité.

Si le projet fait partie d’un programme (portefeuille de projets) plus vaste, PRINCE2 fournit les interfaces nécessaires pour assurer la liaison avec la direction des programmes.

PRINCE2 respecte les standards de facto en matière de gestion de la qualité.

2.1. La relation client/fournisseur / (Customer/supplier relationship)

PRINCE2 part du principe qu’au sein de tout projet cohabitent des groupes hétérogènes d’individus aux intérêts spécifiques dans le projet et sa réussite :

Les clients – qui ont commandé le travail et qui bénéficieront des résultats finaux.

Les utilisateurs – qui exploiteront le(s) produit(s) final(aux); (les termes clients et utilisateurs peuvent désigner le même groupe d’individus dans certaines situations).

Les fournisseurs – qui apportent des ressources spécialisées et/ou des compétences au projet, ou bien encore des biens et des services.

2.2. Adapter la méthode

Les concepts et les processus PRINCE2 constituent un corpus de bonnes pratiques en matière de gestion de projet. Chaque concept et chaque processus doit être appliqué en fonction des besoins spécifiques à chaque projet. Adapter la méthode implique de considérer des problématiques telles que la taille du projet, les risques, le coût, la durée, la qualité, l’importance et l’emplacement. Tenir compte des contextes est un facteur critique au succès de la mise en oeuvre de PRINCE2. La philosophie qui sous-tend chaque concept et chaque processus dans PRINCE2 peut être appliquée à l’identique à tous les projets quelque soit leur taille.

3. Processus de gestion de projet / (Project Management Processes)

PRINCE2 comprend huit processus de gestion, chacun mettant l’accent sur un point particulier tout au long du cycle de vie du projet. Tout projet géré avec PRINCE2 adressera sous diverses formes chacun de ces processus. Les processus ne sont pas séquentiels; certains peuvent être traités en parallèle avec d’autres. La clef d’une utilisation réussie de PRINCE2 consiste à se demander: “Jusqu’où ce processus devrait-il être appliqué à ce projet ?” pour chacun des huit processus.

3.1. Diriger un projet (DP) / (Directing a Project (DP))

Ce processus, actif depuis le démarrage jusqu’à la clôture du projet, est sous la responsabilité du Comité de pilotage. Il en définit les responsabilités :

Approuver l’exposé du projet (Project Brief) et en autoriser l’initialisation.

Autoriser le Document d’initialisation du projet (Project Initiation Document), y compris le cas d’affaires, et attribuer la “propriété” du projet.

Contrôler le statut du projet au terme de chaque séquence avant d’autoriser le passage à la séquence suivante.

Encadrer le chef de projet sur le plan managérial, et réagir aux situations d’exception.

Assurer la liaison avec la direction d’entreprise ou des programmes

Confirmer la clôture du projet.

3.2. Élaborer un projet (EP) / (Strating up a Project (SU))

Il s’agit d’un processus de pré-projet conçu pour réponde à la question fondamentale : “Sommes-nous face à un projet viable et qui vaut la peine d’être engagé?”

Ce processus :

Garantit qu’il existe l’autorité nécessaire pour entreprendre le projet.

Garantit la disponibilité d’une information suffisante concernant les objectifs du projet, son périmètre et les contraintes à envisager.

Conçoit et nomme une équipe de gestion de projet appropriée.

Décide de l’approche à employer pour fournir les livrables requis par le projet.

Crée le plan de la séquence d’initialisation.

3.3. Initialiser un projet (IP) / (Initiating a project (IP))

Processus en charge de s’assurer que le projet peut être entrepris et géré avec succès jusqu’à son terme :

S’assure que toutes les personnes impliquées comprennent le périmètre et les objectifs du projet.

S’assure qu’un cas d’affaires pertinent existe pour le projet.

S’assure que le projet a été planifié et évalué sur le plan financier de manière adéquate.

Évalue les risques identifiés.

Obtient l’approbation du Comité de pilotage avant de passer à la séquence suivante.

L’initialisation est une étape préliminaire lors de tout nouveau projet.

3.4. Contrôler une séquence (CS) / (Controlling a stage (CS))

Ce processus couvre la gestion quotidienne des activités sur le projet. À travers une séquence, il consiste en un cycle d’activités :

Autoriser le travail à être réaliser par l’équipe projet.

Surveiller et communiquer sur l’état d’avancement du projet.

Consigner les problèmes liés au projet.

Évaluer les changements nécessaires.

Prendre les actions correctives nécessaires.

Prendre livraison des produits achevés par l’équipe du projet.

3.5. Gérer la livraison de produits (LP) / (Managing Product Delivery (MP))

Ce processus distingue la gestion du projet de la création ou de la fourniture des produits par l’équipe projet. Il implique :

La négociation et l’acceptation des lots de travaux (Work Packages) produits par le chef de projet.

De s’assurer que le travail requis est effectivement réalisé.

De communiquer et de rapporter sur l’état de progression.

De s’assurer que les produits achevés respectent les critères de qualité requis.

3.6. Gérer les limites de séquences (LS) / (Managing Stage Boundaries (SB))

Ce processus couvre les responsabilités du chef de projet au terme de chaque séquence, ou, si le projet est en exception, permet le lancement d’un plan correctif. Il implique :

Le reporting sur la livraison des produits.

La réévaluation du niveau de risque.

La mise à jour de la documentation de gestion du projet.

La planification de la séquence suivante, ou la production d’un plan d’exception (Exception Plan).

3.7. Clôture de projet (CP) / (Closing a Projet (CP))

Ce processus garantit un terme contrôlé du projet, qu’il s’agisse d’une clôture avec succès ou d’un arrêt prématuré, par :

L’émission de rapports sur l’atteinte des objectifs du projet tels que définis dans le document d’initialisation du projet.

L’émission de recommandations sur les prochaines actions requises.

La planification des revues post-projet.

L’évaluation de la manière dont le projet a été géré et la restitution des retours d’expérience.

Le passage du projet en mode inactif.

3.8. Planifier (PL) / (Planning (PL))

Ce processus décrit les étapes itératives indiquées dans la planification et la replanification du projet. Il est mis en oeuvre en parallèle avec les activités appartenant aux autres processus PRINCE2; il repose sur une technique de planification basée sur le livrable, ceci afin de garantir que les plans tiennent suffisamment compte des exigences liées aux produits :

Rédiger une description de produit (Product Description) du produit final (Final Product).

Créer une structure de décomposition de produit (Product Breakdown Structure) qui identifie les produits requis.

Rédiger des descriptions de produits (Product Descriptions), qui incluent une définition des exigences de qualité, pour chaque produit.

Créer un diagramme de flux des produits (Product Flow Diagram) qui expose l’ordre logique de production des produits et leurs interdépendances.

Identifier les activités requises pour créer les produits.

Estimer la durée et les efforts pour chaque activité.

Evaluer les risques.

Calculer les coûts.

Identifier les points de contrôles (checkpoint) nécessaires.

Documenter le plan, ses prévisions et la documentation de support.

4. Les composants / (Components)

Les composants désignent des aspects clés en matière de gestion de projet mis en oeuvre dans les processus PRINCE2.

4.1. Le cas d’affaires / (Business Case)

Un projet PRINCE2 est « piloté » par son cas d’affaires, qui expose la justification et la logique du projet, y compris les bénéfices attendus, de même qu’une évaluation du rapport coûts / bénéfices.

Le cas d’affaires doit intégrer tous les éléments impactés par le projet, et pas seulement les plus significatifs. Par exemple, il faut éviter de focaliser le cas d’affaires (et donc le projet) sur les bénéfices projetés d’un nouvel équipement, et d’ignorer l’impact sur le personnel, les procédures et les méthodes de travail.

Le cas d’affaires « appartient » au directeur de projet, qui est ultimement responsable de la fourniture des bénéfices escomptés.

4.2. L’organisation

Quelque soit la taille du projet, des accords doivent être conclus sur :

Qui définit les besoins ?

Qui fournit le budget ?

Qui fournit les ressources ?

Qui autorise les changements ?

Qui gère le travail au jour le jour ?

Qui définit les standards à respecter ?

Sur un petit projet, la plupart de ces rôles seront placés sous la responsabilité d’une seule et même personne. Sur un projet d’envergure, plusieurs personnes peuvent assumer chacun des rôles. PRINCE2 fournit une structure de gestion de projet flexible consistant en rôles spécifiques. La plupart de ces derniers peuvent être de fait alloués à une seule personne, être répartis sur plusieurs, ou encore être combinés ensemble.

4.2.1 Le comité de pilotage / (Project Board)

Le comité de pilotage représente les intérêts du business (client), utilisateurs et fournisseurs, et assume la direction et le management du projet. Le comité de pilotage a la responsabilité et l’autorité sur le projet dans ses moindres attributions (mandat de projet / Project Mandate), en lien avec la direction d’entreprise ou des programmes. Le Comité de pilotage est aussi responsable de la bonne marche du projet pour la fourniture du résultat attendu, entendre tel que défini dans le cas d’affaires.

Au lancement d’un nouveau projet, le comité de pilotage :

Approuve l’exposé du projet pour débuter la séquence de démarrage.

Valide les responsabilités et les objectifs du chef de projet.

Décide comment l’assurance projet (Project Assurance) doit être menée.

Attribue les ressources nécessaires pour la séquence d’initialisation.

Confirme les tolérances du project (project tolerances).

Approuve le document d’initialisation du projet (Project Initiation Document).

Tout au long du projet, le comité de pilotage :

Oriente et conseille le chef de projet.

Revoit le statut du projet au terme de chaque séquence et approuve le passage à la séquence suivante.

S’assure que le projet est toujours en bonne voie pour réaliser le cas d’affaires.

Pevoit et approuve tous les plans d’exceptions éventuels (Exception Plans).

Approuve les changements.

Rend compte à la direction d’entreprise ou des programmes.

Peut être amené à recommander l’arrêt du projet.

Au terme du projet, le comité de pilotage :

S’assure que tous les produits ont été livrés de manière satisfaisante.

Confirme que les groupes opérationnels et de support sont prêts à prendre la responsabilité des livrables du projet.

Approuve le rapport de fin de projet (End Project Report), le rapport des retours d’expérience (Lessons Learned Report), et le plan de revue post-projet (Post-Project Review Plan).

Autorise la clôture du projet.

Le comité de pilotage endosse trois rôles : directeur de projet (Executive), responsable des utilisateurs (Senior User) et responsable des fournisseurs (Senior Supplier). Ces trois rôles correspondent aux trois pool d’intérêt dans tout projet : le business, les utilisateurs et les fournisseurs. PRINCE2 est souple sur combien de personnes sont nécessaires pour assumer ces rôles. Ces derniers peuvent être combinés ou mutualisés selon les besoins du projet.

4.2.2. Le directeur de projet / (Executive)

Le directeur de projet est seul responsable du succès final du projet. Il doit s’assurer de sa rentabilité en adoptant une approche de contrôle des coûts en adéquation avec les besoins du business, des utilisateurs et des fournisseurs. Le directeur de projet est « propriétaire » du cas d’affaires.

4.2.3. Le responsable des utilisateurs / (Senior User)

Le responsable des utilisateurs doit s’assurer que les exigences des utilisateurs sont toutes rigoureusement consignées, que ce qui est livré correspond bien aux objectifs, et que les solutions répondent en tous points aux besoins exprimés, dans la limite des contraintes imposées par le cas d’affaires.

4.2.4. Le responsable des fournisseurs / (Senior Supplier)

Ce rôle désigne les ressources nécessaires à la conception, au développement, à la facilitation, à l’approvisionnement et à l’implémentation des produits du projet.

4.2.5. Le chef de projet / (Project Manager)

Le chef de projet est responsable de la gestion quotidienne du projet , sous l’autorité du comité de pilotage. Sa première responsabilité est de s’assurer que le projet délivre bien les produits attendus, en conformité avec les standards de qualité convenus, et les contraintes associées de temps et de coût.

Tout au long du projet, le chef de projet :

Prépare la documentation : document d’initialisation du projet (Project Initiation Document), plans projet et de séquence (Project Plan, Stage Plan).

Obtient l’approbation du comité de pilotage pour tous les plans.

Définit les responsabilités et répartit le travail au sein du projet.

Surveille et contrôle la progression en rapport avec les niveaux de tolérance agréés par le comité de pilotage.

Négocie la performance et la livraison des lots de travaux (Work Packages) avec le(s) chef(s) d’équipe (Team Manager(s)).

Planifie les points de contrôle de séquences.

Assure la liaison avec l’assurance projet (Project Assurance).

Prépare et présente des rapports au comité de pilotage, par exemple, au terme de chaque séquence.

Fait respecter les procédures de contrôle de la qualité et des changements.

S’assure que le risque, la qualité et les enregistrements de problèmes sont maintenus et exploités efficacement.

Prépare tous les plans d’exception potentiels dès lors que les niveaux de tolérance risquent d’être dépassés.

4.2.6. Le chef d’équipe / (Team Manager)

Il s’agit d’un rôle optionnel, généralement associé aux projets d’envergure où des équipes multi-compétences sont employées. Ce rôle peut aussi être utile lorsque le travail sur le projet est réalisé par une tierce partie qui rend compte au chef de projet du client.

Le chef d’équipe :

Négocie les lots de travaux (Work Packages) avec le chef de projet.

Planifie et répartit le travail au sein de l’équipe.

Surveille les progrès de l’équipe et initie les actions correctives nécessaires.

Rend compte des progrès et des problèmes au chef de projet.

Consigne les détails des contrôles de qualité mis en oeuvre.

Assure la liaison avec l’assurance projet (Project Assurance).

4.2.7. L’assurance Projet / (Project Assurance)

L’assurance projet réalise des contrôles périodiques afin de s’assurer que le projet est toujours conforme à ses spécifications, aux standards exigés, et au cas d’affaires. L’assurance projet est placée sous la responsabilité de chaque membre du comité de pilotage; ce rôle peut être délégué, mais il ne doit jamais appartenir au chef de projet. Chacun des aspects suivants de l’assurance projet devrait être couvert :

Business :

Le focus sur le cas d’affaires est maintenu.

Les risques sont sous contrôle.

Le lien est maintenu entre le client est le fournisseur.

Les dépenses et le calendrier sont sous surveillance.

Le projet demeure viable.

Le projet demeure rentable.

Le projet s’accorde avec la stratégie ou le programme.

Utilisateur :

Les besoins et les attentes de l’utilisateur sont satisfaites ou gérées de manière efficace.

Une solution acceptable est en cours de développement.

Spécialiste :

Le lien est maintenu entre le client et le fournisseur.

La compétence du spécialiste sur le projet est reconnue.

Le périmètre du projet n’augmente pas de manière inattendue.

Les standards exigés sont utilisés correctement et fonctionnent.

4.2.8. Le support de projet / (Project Support)

Une équipe peut être dédiée intégralement à un projet ou fournir du support pour plusieurs projets de manière centralisée.; ce rôle peut aussi être endossé par le chef de projet, selon la taille et la nature du projet, ainsi que des capacités de l’organisation.

Le support de projet couvre :

La gestion de la configuration (Configuration Management).

La gestion de la documentation et du contrôle du projet, des revues, des réunions et des communications.

L’apport d’expertise sur les outils de supports, l’évaluation, la planification et les standards au chef de projet.

4.3. Les plans

Dans la méthode PRINCE2, le plan de projet (Project Plan) et les plans de séquence (Stage Plans) sont obligatoires. Si le projet requiert le travail de plusieurs équipes, des plans d’équipe (Team Plans) peuvent aussi s’avérer nécessaires.

Le plan de projet est un document de haut niveau traitant des livrables clés ainsi que des principaux points de contrôle du projet. Il récapitule les exigences en ressources et les coûts induits, et est utilisé par le comité de pilotage comme base de référence pour la surveillance des coûts réels et de la progression tout au long du projet.

Un plan de séquence contient le niveau de détail requis pour un contrôle au jour le jour par le chef de projet. Chaque séquence dispose d’un plan de séquence produit à l’approche du terme de la séquence précédente.

Les plans d’équipe présentent de manière plus détaillée les activités de chaque plan de séquence, et sont généralement préparés en parallèle.

Un plan d’exception peut être produit à tout moment au cours d’un projet. Si le chef de projet prévoit dans un rapport d’exception (Exception Report) qu’une séquence est susceptible de dépasser les seuils de tolérance convenus avec le comité de pilotage, il peut exiger en retour la levée d’un plan d’exception (Exception Plan). La même chose peut se produire si c’est le plan de projet ou le plan d’équipe qui sont susceptibles de dépasser les tolérances admises. Le plan d’exception remplacera alors le plan en cours, introduisant de nouvelles exigences en termes de volume de travail et de ressources, nécessaires pour staisfaire aux contraintes réévaluées.

Tous les plans dans PRINCE2 contiennent les mêmes informations, bien qu’à différents niveaux de détail :

Représentations graphiques (ex. : diagramme de Gantt).

Expression des besoins en ressources et en budget.

Description du plan.

Pré requis et prévisions.

Dépendances externes.

Risques.

Tolérances.

4.4. Les contrôles / (Controls)

Les contrôles sous PRINCE2 permettent de s’assurer que le projet produit les bons livrables, au bon niveau de qualité, au respect des échéances de temps, et qu’il demeure viable vis-à-vis du cas d’affaires.

Les principaux contrôles sont :

4.4.1. L’initialisation du projet / (Project Initiation)

Le projet doit-il être lancé ?

4.4.2. L’évaluation de fin de séquence / (End stage assessment)

Le projet est-il toujours actif ? Les risques sont-ils sous contrôle ? Le cas d’affaire est-il toujours viable ? La prochaine séquence doit-elle être enclenchée ?

4.4.3. Le rapport des points clés / (Highlight reports)

Rapports réguliers du chef de projet à destination du comité de pilotage.

4.4.4. Les rapports d’exception / (Exception Reports)

Alerte précoce en cas de dépassement probable des niveaux convenus de tolérance.

4.4.5. La clôture de projet / (Project closure)

Le projet a-t-il produit tous les livrables attendus ? Quels enseignements ont pu être tirés ?

4.4.6. Les séquences / (Stages)

Le découpage en séquences offre au comité de pilotage un meilleur contrôle du projet. Le comité de pilotage ne s’engage que dans une seule séquence à la fois.

4.4.7. La tolérance / (Tolerance)

La tolérance désigne la déviation acceptable d’un plan sans qu’il soit nécessaire d’en référer au niveau de gestion supérieur. La tolérance peut être calibrée en rapport avec les échéances, les coûts, le périmètre, la qualité, les risques et les bénéfices. En cas de prévision de dépassement par l’un quelconque des plans des niveaux de tolérances convenus, le plan correspondant passe en mode « exception ».

4.4.8. Les descriptions de produit / (Product Descriptions)

Les descriptions de produit stipulent les caractéristiques des produits à livrer, les standards à utiliser ou à suivre, les critères de qualité à appliquer pour s’assurer que le produit répond aux objectifs, et la méthode à employer pour contrôler la qualité du produit.

4.4.9. Les lot de travaux / (Work Package)

Le travail à réaliser par l’équipe de projet est consigné dans un lot de travaux, lequel requiert l’accord préalable du chef de projet pour être entrepris.

4.4.10. Les incidences de projet / (Project Issues)

Les incidences de projet peuvent émaner de situations, ou être de natures diverses telles que :

Nouvelles exigences des utilisateurs.

Changements dans la législation.

Changements dans l’organisation ou le business.

Fournisseurs dans l’incapacité d’approvisionner.

Changements dans les ressources disponibles.

Questions ou inquiétudes au sujet du projet.

Dans PRINCE2, toutes les incidences de projet sont évaluées pour déterminer leur impact sur le projet. Toutes les levées d’incidences de projet sont consignées et toutes les actions correctives ou de résolution sont gérées et documentées.

4.4.11. Le recueil des risques / (Risk Log)

Tous les risques identifiés sont consignés et les analyses, contre-mesures et statuts associés régulièrement mis à jour par le chef de projet et le comité de pilotage, tout au long du cycle de vie du projet.

4.5. La gestion du risque / (Management of risk)

La gestion du risque consiste à maintenir l’exposition du projet aux risques à un niveau acceptable moyennant des contre-mesures appropriées, dans un souci constant de rentabilité.

L’analyse du risque implique l’identification et l’évaluation des risques potentiels pouvant affecter le projet. L’évaluation du risque estime la probabilité de survenue du risque et son impact sur le projet en cas de matérialisation de la menace. Une fois les risques identifiés, les initiatives de réduction du risque disponibles doivent être considérées et les mesures les plus appropriées retenues.

Les activités de la gestion du risque incluent :

La prévention – Supprimer l’origine du risque en évitant les pratiques à risque toutes les fois que c’est possible. Des contre-mesures sont mises en œuvre qui soit empêchent la menace de se matérialiser, soit minimise ou anihile son impact sur le projet ou le business.

La réduction – Engager les actions nécessaires pour permettre le contrôle du risque soit en réduisant sa probabilité de survenue, soit en limitant son impact sur le projet à un niveau acceptable.

Le transfert – Il s’agit là d’une forme spécifique de réduction du risque dans laquelle l’impact est renvoyé vers une tierce-partie à travers, par exemple, une politique d’assurance ou une clause de pénalité.

L’acceptation – Tolérer le risque; si aucune action de réduction ne peut être engagée à un coût raisonnable, ou si la probabilité de survenue et l’impact consécutif sont maintenus à un niveau acceptable.

La contingence – Actions planifiées pour être mise en œuvre lors de la matérialisation du risque.

La gestion du risque implique la planification et l’implémentation des ressources nécessaires aux activités de prise en charge. Une fois en place, ces dernières devront faire l’objet d’une surveillance constante et de rapports réguliers afin de s’assurer qu’elles produisent bien les effets désirés.

La gestion du risque est une activité continue tout au long du cycle de vie du projet, et concerne tous les membres de l’organisation du projet.

4.6. La qualité dans un environnement projet / (Quality in a project environment)

Les standards de qualité et les responsabilités associées pour garantir la conformité du projet à ces standards sont dérivés de diverses sources telles que : attentes du client en matière de qualité, exigences des standards ISO, et systèmes existants de gestion de la qualité.

La planification de la qualité implique des accords sur :

Quelles seront les modalités de contrôle pour chaque produit ? (Défini au début du projet.)

Quand interviendront les contrôles ? (Défini dans la séquence correspondante ou les plans d’équipe.)

Par qui chaque produit sera-t-il testé ? (Défini dans la séquence correspondante ou les plans d’équipe.)

La qualité est atteinte au moyen de la combinaison des activités suivantes :

Définir les critères de qualité pour chaque produit en termes mesurables.

Développer des produits en accord avec les standards de qualité convenus.

Contrôler la qualité de tous les produits livrés.

4.7. La gestion des configurations / (Configuration management)

La gestion des configurations représente est un aspect essentiel du contrôle qualité en permettant un suivi précis des actifs d’un projet.

Les cinq fonctions essentielles de la gestion des configurations sont :

La planification – Décider du niveau de détail requis.

L’identification – Spécifier tous les composants du produits final.

Le contrôle – “Geler” le développement des produits et appliquer les futurs changements selon une procédure formelle de contrôle des changements.

Le suivi du statut – Enregistrer et consigner toutes les données d’historique pour chaque produit.

La vérification – Revoir et auditer pour s’assurer que les produits réels correspondent bien aux prévisions.

4.8. Le contrôle du changement / (Change Control)

Tout au long du cycle de vie du projet se poseront des problèmes divers, des changements et des requêtes émanées à la fois des participants eux-mêmes, des parties prenantes ainsi que des intervenants externes impliqués. Le contrôle des changements fournit un mécanisme formel destiné à certifier que toutes les incidences de projets (Project Issues) sont correctement journalisées, analysées, et que les actions correctives appropriées sont engagées.

La prise en compte des incidences de projet impliquent d’évaluer :

L’impact sur le cas d’affaire du projet et les bénéfices attendus.

L’impact sur les risques identifiés ou la génération de nouveaux risques.

L’impact sur le coût, le temps, la qualité et le périmètre.

Les incidences de projet qui impliquent des changements sont traitées ou comme des demandes de changements (Requests for Change) ou comme des « hors-spécification » . Une requête de changement désigne une modification requise sur un produit. Une « hors-spécification » indique qu’un produit va échouer (ou a échoué) à atteindre ses exigences de conception.

Article extrait du site ITIL.FR – Le portail communautaire francophone des Meilleures Pratiques.

Laisser un commentaire

23 avril 2010

Aligner ITIL et MOF (Microsoft Operations Framework)

Filed under: ITIL,MOF — urbandot @ 23 11 10 04104
Tags: ITIL, MICROSOFT, MOF

Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

Introduction à ITIL et à MOF

Dans la théorie, il n’y a aucune différence entre la théorie et la pratique. Dans la pratique il y en a une.
(Yogi Berra)

Qu’est-ce qu’ITIL ?

Le référentiel ITIL offre une approche structurée pour la fourniture de services IT de qualité. ITIL fut initialement développé dans les années 80-90 par le CCTA (Central Computer and Telecommunications Agency, aujourd’hui l’Office of Government Commerce, OGC), sous contrat avec le gouvernement britannique. Depuis lors, ITIL a fourni non seulement un cadre de référence fondé sur des bonnes pratiques, mais également une approche et une philosophie partagées par tous ceux qui l’appliquent au quotidien.

Structure principale : Le cycle de vie des services

ITIL Version 3 offre une approche de gestion des services fondée sur le principe du cycle de vie. Ce modèle d’organisation fournit des clefs sur la gestion des services et la manière dont les divers composants sont liés entre eux et au cycle de vie dans son ensemble.

Le cycle de vie des services se décompose en cinq phases. Chacun des volumes ITIL V3 décrit l’une de ces phases :

Stratégie de services
Conception de services
Transition de services
Exploitation de services
Amélioration continue des services

ITIL V3

Schéma 1 : Le cycle de vie des services ITIL V3.

La stratégie constitue l’axe central du cycle de vie des services ; c’est la phase de l’élaboration de la politique et des objectifs, qui conditionne toutes les autres. Les phases Conception de services, Transition de services et Exploitation de services implémentent la stratégie avec pour constantes l’ajustement et le changement. La phase continuelle d’Amélioration des services est synonyme de capitalisation de savoir et d’amélioration, et s’applique à toutes les autres phases du cycle. Elle initie des programmes et des projets d’amélioration, et leur attribue des priorités selon les objectifs stratégiques de l’organisation.

Composants principaux

Chaque phase est sous-tendue par un système de processus, d’activités et de fonctions, qui décrivent comment les choses devraient être réalisées. Les sous-systèmes des cinq phases entretiennent des relations de dépendances réciproques, et la plupart des processus sont à cheval sur plusieurs phases.

Qu’est-ce que MOF ?

Publié initialement en 1999, le Microsoft Operations Framework (MOF) constitue l’approche structurée de Microsoft pour aider ses clients à atteindre l’excellence opérationnelle, au travers du cycle de vie complet des services IT. MOF a été créé à l’origine pour apporter aux professionnels de l’IT les compétences et les processus utiles à l’alignement de leur activité de gestion des plates-formes Microsoft, en vue d’atteindre des niveaux élevés de fiabilité et de sécurité, de façon rentable.

La nouvelle version, MOF 4.0, a été créée pour relever les nouveaux défis IT : démontrer la valeur business de l’informatique, répondre aux conditions de normalisation, et améliorer la capacité organisationnelle. MOF intègre également les meilleures pratiques issues du Microsoft Solutions Framework (MSF).
MOF offre des conseils pratiques pour la gestion des tâches et des activités quotidiennes; enfin, le corpus de connaissances peut être exploité gratuitement, y compris dans le cadre d’une réutilisation sous licence Creative Commons Attribution.

Structure principale : le cycle de vie des services IT

Le cycle de vie des services IT décrit l’évolution d’un service :

Planification, optimisation et alignement avec la stratégie business.
Conception et livraison au respect des exigences du client.
Suivi d’exploitation et support auprès de la communauté des utilisateurs.

Le Cycle de vie des services IT exploite et définit :

la gouvernance IT,
la gestion des risques,
la conformité,
les rôles et responsabilités,
l’organisation des équipes,
la gestion des changements.

Le cycle de vie des services IT de MOF se décompose en trois phases itératives et inclut également une couche de gestion active tout au long du cycle de vie :

Phase de planification : Planifier et optimiser une stratégie de services IT afin de soutenir les objectifs et la stratégie du business.
Phase de livraison : s’assurer que les services IT sont développés efficacement, déployés avec succès, et prêts pour l’exploitation.
Phase d’exploitation : s’assurer que des services sont exploités, maintenus, et soutenus conformément aux attentes et aux exigences du business.

Couche de gestion :

A la base du cycle de vie des services IT.
Gouvernance IT.
Gestion des risques, de la conformité, des changements et des configurations.
Fournit des indications sur les rôles et les responsabilités.
Les processus dans cette couche s’appliquent à toutes les phases du cycle de vie.

MOF

Schéma 2 : MOF 4.0 – Cycle de vie de services IT.

Composants principaux

Chaque phase du cycle de vie des services IT intègre des fonctions de gestion de services (Services Management Functions, SMF) qui définissent et structurent les processus, les personnes, et les activités nécessaires à l’alignement des services IT sur la stratégie business. Les fonctions de gestion de services sont regroupées en phases qui reflètent le cycle de vie des services IT. Chaque fonction de gestion de services est ancrée dans une phase du cycle de vie, et contient un ensemble unique de buts et de résultats soutenant les objectifs de cette phase.

Chaque fonction de gestion de services comporte de trois à six processus clefs, chaque processus étant composé de une à six activités clefs.

Lors de chaque phase du cycle de vie, des revues de gestion (Management Revues, MR) sont mises à profit pour déterminer le statut des services IT et décider du passage à la phase suivante. Les revues de gestion sont des contrôles internes visant à s’assurer que les buts sont atteints d’une façon appropriée, et que l’intérêt business est pris en compte tout au long du cycle de vie de services.

Alignement d’ITIL et de MOF

Les gens n’ont jamais assez de temps pour effectuer le travail correctement, mais ils ont toujours assez de temps pour le recommencer.
(Patrick O’Beirne)
En termes d’approches, les deux référentiels emploient une structure basée sur le principe de cycle de vie. Si tous deux exploitent des processus et des fonctions, ils le font dans des proportions très différentes : ITIL décrit beaucoup de composants en termes de processus et d’activités, et intègre seulement quelques fonctions, alors que MOF est presque entièrement basé sur des fonctions de gestion de service. Cette différence n’est pas aussi évidente qu’il pourrait y paraître, ITIL employant le terme « processus » pour beaucoup de composants qui peuvent être assimilés à des fonctions.

ITIL suit une approche par étapes dans le cycle de vie, et la plupart des composants décrits dans une phase s’appliquent également, dans une plus ou moins large mesure, aux phases connexes. Le contrôle du cycle de vie dans MOF est beaucoup plus sélectif, et utilise des jalons spécifiques qui marquent le progrès au travers les diverses étapes du cycle de vie. Les composants de MOF qui s’appliquent à plus d’une seule des phases du cycle de vie sont extraites et décrites dans la couche de gestion.

Les deux référentiels sont décrits comme des « cadres de pratique » plus que comme des « cadres de processus. » La différence principale étant qu’ITIL se concentre plus spécifiquement sur le « quoi », alors que MOF couvre à la fois le « quoi » et le « comment. »

Les techniques de modélisation d’ITIL et de MOF ne diffèrent pas significativement à première vue : les deux référentiels employant des descriptions textuelles détaillées, soutenues par des organigrammes et des diagrammes de flux. ITIL documente ses meilleures pratiques en présentant des processus, des activités, et des fonctions pour chaque phase du cycle de vie. Les composants de MOF présentent quant à eux une structure plus rigide : chaque fonction de gestion de services comporte des processus clefs, chaque processus des activités clefs, et la documentation des fonctions de gestion de services et des revues de gestion est structurée dans un format très concis, couvrant les données d’entrée et de sortie, les questions clé, et les meilleures pratiques pour chaque composant. Cette structure rigide soutient l’uniformité globale du référentiel, et assiste le praticien dans le choix des composants de MOF les mieux adaptés aux problématiques les plus sensibles dans son périmètre.

L’activation et l’implémentation d’ITIL et de MOF n’appartiennent pas en plein à la documentation des référentiels. Sur ce point, ITIL préconise l’approche « adopter et adapter ». Les structures de support telles que les rôles et les qualifications organisationnelles sont décrits pour chaque phase, mais les recommandations de mise en œuvre effective ne sont pas documentées. MOF, à l’instar d’ITIL, fournit un ensemble de recommandations et de meilleures pratiques qui peuvent être suivies en intégralité ou en partie seulement, pour la prise en compte de problèmes locaux. Les deux référentiels se contentent donc de fournir des conseils et du guidage, et relèguent au praticien la responsabilité des choix de mise en œuvre dans son contexte spécifique.

Les structures de support dans ITIL ne participent pas de la documentation de référence : bien qu’une gamme pléthorique de produits et de solutions se revendiquent aujourd’hui d’une compatibilité avec ITIL, (et l’existence anecdotique de quelques systèmes officieux d’accréditation), le corpus ITIL reste très en retrait en ce qui concerne les produits, les solutions commerciales et leur certification, au profit d’une attitude de neutralité. Tout au contraire, la compatibilité de MOF est clairement établie. Microsoft assure l’alignement constant d’un vaste ensemble d’outils de sa plate-forme avec le référentiel MOF. Et bien que MOF ne s’applique pas strictement aux seuls produits de gestion Microsoft, la documentation accessible en ligne sur le site Web Microsoft TechNet fournit des informations détaillées sur l’utilisation de produits spécifiques issus de la gamme Microsoft.

Différences

Bien qu’ITIL et MOF partagent beaucoup de points en commun, les deux référentiels présentent également quelques différences notables :

Coût : le corpus ITIL est accessible au sein d’une documentation de référence composée de cinq livres distribués par divers canaux, lors même que le référentiel MOF est disponible gratuitement sur l’Internet. Là où le copyright d’ITIL restreint significativement les droits à l’exploitation du référentiel, Microsoft a fait le choix de distribuer le référenrtiel MOF sous licence Creative Commons Attribution, ce qui en permet une libre réutilisation commerciale.

Développement : la phase de conception de services d’ITIL se concentre sur les principes de conception, là où la phase de livraison dans MOF se concentre sur le développement réel des services. L’approche retenue dans MOF est résolument basée sur des principes issus du mode gestion de projet qui caractérise cette phase du cycle de vie.

Reporting : ITIL intègre une entité spécifique qui décrit la façon de rendre compte dans la phase d’amélioration continue des services, tandis que MOF a intégré le reporting comme une activité standard dans les fonctions de gestion de services.

Gestion des demandes : alors qu’ITIL V2 proposait une gestion combinée des incidents et des demandes de service au sein d’un même processus, ITIL V3 a nettement dissocié la résolution des incidents et la prise en compte des demandes de service en deux pratiques traitées séparément. MOF reste beaucoup plus proche de la méthode telle que préconisée dans ITIL V2, en regroupant toutes les demandes du client au sein d’un flux unique de traitement, qu’il s’agisse de : demandes de résolution suite à incident, demandes d’information, demandes de modification de services existants ou création de nouveaux services. Dans ce dernier cas, et si la demande implique la création d’un nouveau service ou d’un service non-standard, un processus de changement séparé peut être déclenché.

Construction du cycle de vie : ITIL utilise cinq phases pour son cycle de vie : la stratégie, la conception, la transition, l’exploitation, et l’amélioration continue, délivrées conformément aux principes du modèle PDCA (Plan/Do/Check/Act). Le cycle de vie de MOF comporte quant à lui seulement trois phases : la planification, la livraison et l’exploitation, avec de plus une couche transverse couvrant les composants applicables à toutes les phases du cycle de vie. Par conséquent, un certain nombre de pratiques appliquées tout au long du cycle de vie de MOF ne sont en revanche décrites principalement que dans une ou quelques phases seulement du cycle de vie ITIL. Par exemple, la gestion des risques appartient à la couche de gestion dans MOF, alors que dans ITIL elle est principalement limitée à la stratégie et à l’amélioration continue des services. Il en va de même pour la gestion des changements et des configurations applicable tout au long du cycle de vie de MOF, alors que dans ITIL elle se retrouve concentrée dans la phase de transition.

Organisation : ITIL décrit des rôles et des structures d’organisation pour chaque phase du cycle de vie. MOF soutient les meilleures pratiques pour les structures organisationnelles en appliquant l’approche Microsoft Solutions Framework : tout au long du cycle de vie de MOF, les responsabilités sont documentées et clairement explicitées, et des règles générales sont assignées à la couche de gestion sous-jacente.

Gouvernance : Les deux cadres illustrent clairement la différence entre gouvernance et gestion. ITIL décrit la théorie et la pratique en matière de gouvernance dans les phases de stratégie et d’amélioration continue des services de son cycle de vie, et se réfère aux impératifs de gouvernance dans la plupart des autres phases. MOF documente explicitement les responsabilités dans toutes les phases du cycle de vie et dans la couche de gestion, identifiant des décideurs et des dépositaires, et intégrant l’évaluation des performances. MOF intègre spécifiquement la gestion des risques et de la conformité au sein de la couche de gestion, soutenant la gouvernance tout au long du cycle de vie. Des revues explicites de gestion sont employées dans le référentiel MOF comme mécanismes de contrôle.

Positionnement

Cette section développe les principaux paradigmes propres à chaque référentiel et évoqués plus haut.

Cycle de vie

Dans l’ensemble, les cycles de vie d’ITIL et de MOF présentent un aspect plutôt similaire, bien que les phases en tant que telles ne puissent être comparées sur une base linéaire.

Cycles de vie ITIL / MOF

Schéma 3 : Comparaison des cycles de vie.

Il existe quelques différences majeures entre les cycles de vie d’ITIL et de MOF :

Les phases du cycle de vie d’ITIL comportent des processus, des activités, et des fonctions étalées sur plusieurs phases. Dans MOF, les fonctions de gestion de services qui s’appliquent à plus d’une phase ont été extraites et regroupées au sein de la couche de gestion, soutenant le cycle de vie entier de MOF.

Les transitions de phase à l’intérieur du cycle de vie de MOF sont contrôlées par plusieurs revues de gestion. Ces revues sont employées pour déterminer le statut des services et ainsi décider du passage à la phase suivante. ITIL emploie également un certain nombre de tests d’aptitude pour évaluer le progrès dans les phases du cycle de vie, mais de façon moins explicite et formalisée.

Les personnes – les processus – la technologie (PPT)

Quatre-vingt pour cent des périodes d’indisponibilité non-planifiées sont provoqués par des problèmes de processus et de personnes, telles que des pratiques de gestion des changements inadaptées, alors que le reste est provoqué par des défaillances et des pannes techniques.

(Donna Scott, Gartner, Inc., 2003)

ITIL et MOF sont foncièrement focalisés sur les processus. Les deux référentiels documentent les activités devant être réalisées pour faire face aux problèmes et aux tâches quotidiens, au sein des organisations de service. Les deux référentiels emploient également la même définition formelle du concept de « processus », basée sur les normes reconnues de l’ISO.

Cependant et dans les deux cas, la documentation de référence apparaît en grande partie comme un mélange de processus, de personnes, et de technologies, et donc sous forme de procédures, d’instructions de travail, et de fonctions. Il en est ainsi car il s’agit de refléter fidèlement la perception réelle des usagers dans leur pratique quotidienne.

Les lecteurs recherchant « des descriptions de processus pures » ou des « modèles » de processus ne trouveront donc ces derniers ni dans ITIL ni dans MOF. Et bien qu’ITIL emploie fréquemment le terme « processus » pour nombre de ses composants, la plupart de ces derniers sont en réalité des fonctions. MOF emploie le terme de fonction de gestion de services tout au long du référentiel pour les désigner..

Les structures d’organisation diffèrent singulièrement dans les deux référentiels. Si certains rôles spécifiques d’ITIL et ceux de MOF peuvent se confondre, les deux cadres contiennent malgré tout une liste importante de rôles distinctifs. Ceci s’explique en grande partie sur une différence de point de vue : ITIL s’appuie sur ses pratiques au travers du spectre détaillé des rôles, alors que MOF repose sur des responsabilités de base : support, exploitation, service, conformité, architecture, solutions, et gestion. MOF applique le référentiel MSF comme système de référence pour ces structures d’organisation pour le soutien des performances. Dans de plus grandes organisations, les rôles de MOF peuvent être enrichis, même si dans la plupart des cas les rôles génériques s’avèrent suffisants. L’équipe SMF de MOF est explicitement concentrée sur la gestion du personnel informatique.

La technologie est seulement couverte à un niveau abstrait dans ITIL : le référentiel reste éloigné des outils commerciaux, et décrit seulement quelques prérequis de base. MOF au contraire est profondément impliqué au plus proche des technologies et des solutions. Bien que MOF ait été défini de telle manière qu’il ne repose pas exclusivement sur une seule technologie, la plate-forme de technologie de Microsoft est fortement alignée sur les pratiques telles que documentées dans MOF. Le site Web de MOF est ainsi inclus dans la documentation TechNet sur les produits Microsoft.

Répartition des phases, des processus et des activités

Les niveaux stratégiques sont couverts dans les deux référentiels. ITIL documente ses meilleures pratiques sur des décisions à long terme dans la phase de stratégie. MOF en fait de même dans la phase de planification, et en assure le support à travers la couche de gestion.

Les niveaux tactiques sont couverts de façon similaire dans les deux référentiels : ITIL concentre ces derniers dans les phases de conception de services et d’amélioration continue des services, tandisque MOF décline ses conseils tactiques dans la phase de livraison, la couche de gestion et dans la phase d’exploitation (gestion de problèmes).

Les niveaux opérationnels sont presque exclusivement concentrés dans la seule phase d’exploitation de services, dans les deux référentiels.

Les phases du cycle de vie d’ITIL sont principalement située dans le domaine de gestion de la technologie, soulignant qu’ITIL soutient explicitement les organismes qui fournissent des services. Les activités qui se rapportent aux spécifications des exigences de service et à la gestion des architectures de données d’entreprise peuvent typiquement être trouvées dans la colonne moyenne de la matrice 3×3 SAME.

ITIL V3 - Matrice 3x3 SAME

Schéma 4 : Positionnement d’ITIL V3 dans la matrice 3×3 SAME.

Ceci s’applique également à MOF. La phase de planification (PLANIFIER) de MOF est en grande partie positionnée au niveau de la stratégie et se concentre sur le domaine de gestion de la technologie. La phase de livraison (FOURNIR) est positionnée à l’identique, mais également aux niveaux tactiques et opérationnels. La phase d’exploitation (EXPLOITER) se situe clairement au niveau opérationnel du domaine de gestion de la technologie, excepté la gestion (très tactique) des problèmes.

La couche de gestion (GERER) dans MOF implique chacun des trois niveaux et concerne également sur le domaine de gestion de la technologie.

MOF - Matrice 3x3 SAME

Schéma 5 : Positionnement de MOF dans la matrice 3×3 SAME.

Planier-Faire-Vérifier-Agir

ITIL suit explicitement le modèle d’amélioration continue de la qualité de Demings PDCA pour l’amélioration continue des services, des processus, et des fonctions tout au long du cycle de vie des services.
MOF ne mentionne pas explicitement PDCA en tant que mécanisme, mais suit malgré tout ses principes tout au long du cycle de vie, et dans toutes les fonctions de gestion de services. Planifier-faire-vérifier est un basique lors de l’implémentation des fonctions de gestion de services, et plusieurs instances de vérification peuvent être consultées lors des revues de gestion tout au long du cyle de vie.

Roue de Deming

Schéma 6 : la roue de Deming.

The Microsoft Operations Framework 4.0 is provided with permission from Microsoft Corporation

Article extrait du site ITIL.FR – Le portail communautaire francophone des Meilleures Pratiques.

Laisser un commentaire

Lean Six Sigma : tour d’horizon des techniques

Filed under: Uncategorized — urbandot @ 15 03 27 04274

Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

Introduction

La racine commune des référentiels Lean et Six Sigma remonte à l’époque où de fortes pressions sur la qualité et la performance ont commencé à peser sur le secteur industriel. Lean et Six Sigma se sont alors imposés respectivement comme méthode d’optimisation de la fabrication automobile, et démarche qualité d’excellence pour l’éliminiation des défauts, par la réduction des variations au coeur des processus de l’industrie des semi-conducteurs. Il n’est d’ailleurs pas surprenant de constater que les tout premiers adeptes de la méthode Lean Six Sigma soient pour la plupart issus des unités de soutien des services de grands groupes industriels tels que GECapital, Caterpillar Finance, ou Lockheed Martin.

Lean Six Sigma pour les services est une méthodologie d’amélioration des affaires qui maximise la valeur pour les actionnaires en réalisant les meilleurs taux d’amélioration de la satisfaction client, de coût, de qualité, de rapidité des processus, et de retour sur capital investi. La fusion des méthodes d’amélioration Lean et Six Sigma décuple les performances de chacune et permet de dépasser leurs limitations intrinsèques :

Lean ne peut pas mettre un processus sous contrôle statistique.
Six Sigma seule ne peut améliorer considérablement la vitesse de traitement ou réduire le capital investi.
Tous deux permettent la réduction du coût lié à la complexité.

Ironiquement, Six Sigma et Lean ont souvent été considérées comme des initiatives rivales. Les amateurs de Lean arguant que Six Sigma accorde peu d’attention à tout ce qui concerne la vitesse et le débit, tandis que les partisans de Six Sigma soulignaient quant à eux le fait que Lean ne tient pas compte de concepts clés tels que les besoins des clients et la variation. .

Toutesfois, ces arguments, le plus souvent utilisés pour défendre un choix un sur l’autre, ne doivent pas faire perdre de vue que si chaque méthode à ses avantages et ses inconvénients, elles demeurent avant tout éminemment complémentaires.

Six Sigma

Six Sigma est une technique de gestion qui vise à développer et fournir des produits et des services proches de la perfection. Le parti pris selon lequel Six Sigma est seulement utile pour les problèmes qui sont «difficiles à trouver, mais faciles à corriger” a fréquemment été soutenu, par opposition à l’approche radicale de restructuration (reengineering), dont les partisans se concentrent sur des problèmes qui sont “faciles à trouver, mais difficiles à corriger.”

Le terme « Six Sigma » fait référence à des constructions statistiques qui mesurent jusqu’à quel point un processus donné s’écarte de la perfection. Six Sigma est un processus de même qu’une discipline qui mesure le nombre de défauts existant au sein d’un processus d’affaires, puis détermine de façon systématique comment les supprimer. Six Sigma peut être utilisé pour un éventail très large d’activités d’amélioration des processus, et s’applique à de nombreux types de processus, dont la nature des attributs mesurés peut varier considérablement.

Les principes de qualité appliqués lors de l’implémentation de Six Sigma sont presque toujours définis en termes de vision de l’entreprise et de sa stratégie. Les processus sont développés à partir du point de vue du client, et activés par un engagement de l’organisation à raisonner en termes de processus.

Les impératifs de performance, fiabilité, prix, respect des délais de livraison, service et précision définissent les objectifs. L’orientation client initie la connaissance du marché, qui peut à son tour éclairer la nécessité de changement de processus, dans les domaines où l’entreprise peut ajouter de la valeur, ou implémenter des améliorations sollicitées par les clients eux-mêmes.

Les partisans de Six Sigma partent du principe que les clients ont intérêt à comparer, non pas la performance moyenne des entreprises, mais plutôt les performances relatives des processus utilisés pour la fourniture des biens ou des services.

Méthode rigoureuse, Six Sigma exige qu’un processus ne produisent pas plus de 3,4 défauts par million d’occurrences dudit, bien que son objectif principal reste l’amélioration continue. En faitt très peu d’organisations peuvent prétendre avoir jamais atteint l’objectif Six Sigma de 3,4 défauts par million.

Les principes de Six Sigma s’appliquent non seulement à l’industrie, mais également à la prestation de services.

Six Sigma repose sur seulement quelques concepts clefs :

Facteurs clés de succès (Critical to quality) : Attributs ayant le plus de valeur pour le client.
Défaut (Defect) : Défaut de fourniture.
Capacité du processus (Process capability) : Ce qu’un processus peut fournir.
Variation (Variation) : Ce que le client voit et ressent.
Stabilité des opérations (Stable operations) : Garantir des processus cohérents et prévisibles pour améliorer la perception et le ressenti du client.

Lean

Les origines de la méthode Lean remontent bien avant le XXe siècle, bien que la dénomination en tant que telle ne soit apparue que bien plus tard. Le terme Lean provient du travail de recherche d’un étudiant au MIT, dans le cadre d’une étude sur les différences ayant existé entre certains constructeurs automobiles japonais et nord-américains.

Les processus clés de Lean ont tous pour objet l’identification des « déchets » et / ou « des activités sans valeur ajoutée » du point de vue du client, puis de déterminer comment les élminier selon la « bonne » méthode. Par « déchets » il faut entendre l’activité ou les activités que le client ne veux pas payer et / ou qui n’ajoutent aucune valeur au produit ou service du point de vue du client.

Au cœur du Lean repose la détermination de la valeur. La valeur est définie comme un élément ou une caractéristique pour lesquels un client est prêt à payer. Tous les autres aspects du processus sont considérés comme des déchets. Le référentiel Lean est utilisé comme un outil pour concentrer les ressources et les énergies sur la production des caractéristiques à valeur ajoutée, tout en identifiant et en éliminant les activités sans valeur ajoutée.

Lean Six Sigma

Lean Six Sigma est une méthodologie rigoureuse qui s’applique sur les processus (et non pas sur les problèmes) dans le but de :

Améliorer la satisfaction des clients.
Améliorer la performance financière de l’entreprise.
Répondre aux objectifs stratégiques définis par la Direction Générale.

La focalisation sur les processus stratégiques permet de :

Se concentrer sur les valeurs définies par le client (voice of customer).
Se concentrer sur les attentes des actionnaires (voice of buisiness).
Simplifier les processus : flux d’informations, de production.
Supprimer les dysfonctionnements.
Accélérer les processus en gérant et optimisant les ressources.
Réduire la dispersion des processus organisationnels.
Améliorer les performances opérationnelles et les garantir (capacité des processus).
Identifier et agir sur les facteurs influents du processus.
Améliorer les conditions de travail, réduire le stress.
Faire travailler ensemble le personnel issu de différents services.
Donner aux « opérationnels » les moyens et outils d’amélioration.

Les facteurs de réussite du déploiement du Lean six sigma reposent sur quatre fondamentaux :

L’application rigoureuse de la méthodologie Lean Six Sigma – Lean Six Sigma est une méthodologie rigoureuse, structurée qui doit être respectée à la lettre. Les candidats Green Belt et Black Belt doivent se soumettre à une sélection attentive suivant des critères précis. Les processus à améliorer doivent également faire l’objet d’une sélection sur des critères relatifs aux objectifs stratégiques de l’entreprise. Le projet global d’implémentation et du déploiement du Lean Six Sigma doit être structuré, en particulier par la mise en place de Champions et par un comité de pilotage du projet.

L’approche « gestion de projet » – Lean Six Sigma est une démarche d’amélioration continue qui se déploie au travers de projets Black Belt (gains importants, durée du projet : 6 à 8 mois) ou Green Belt (gains intéressants, projets plus courts). L’approche du management par projet est un pré requis pour lancer et réaliser des chantiers Lean Six Sigma.

La conduite du changement – La mise en œuvre du Lean Six Sigma est un facteur de changement dans les pratiques et mises en œuvre quotidiennes des processus. Un accompagnement à la conduite du changement doit être pris en compte au niveau :

des modifications des tâches, des pratiques individuelles et collectives du travail,

des modes de fonctionnement : type de management, approche processus, structure organisationnelle,

des changements culturels demandés et des résistances éventuelles,

de la gestion des polyvalences et poly compétences du personnel,

un mode de communication et d’information interne.

Le management par les processus

Lean Six sigma a pour objectifs essentiels d’améliorer la performance des processus, il ne s’agit pas de résoudre des problèmes : les méthodologies de résolution de problèmes sont un bon complément : PDCA, G8D, MRP.

Complémentarité

Six Sigma

Insiste sur la nécessité d’identifier les opportunités d’amélioration et élimine les défauts tels que définis par les clients.
Reconnaît que la variation entrave la capacité à fournir de manière fiable des services de haute qualité.
Requiert des décisions orientées sur les données et intègre un ensemble complet d’outils de qualité au sein d’un cadre puissant pour une résolution efficace des problèmes.
Fournit une infrastructure culturelle efficace, efficiente et très normative pour l’obtention de résultats durables.

Lean

Maximise la vitesse des processus.
Fournit des outils pour analyser les flux de processus et les détais de traitement pour chaque activité au sein d’un processus.
Distingue les activités à valeur ajoutée des activités sans valeur ajoutée, et exploite des outils pour réaliser son objectif d’élimination des causes profondes de l’absence de valeur ajoutée de certaines activités et des coûts consécutifs.
Fournit un moyen de quantifier et d’éliminer le coût de la complexité.

Les 8 types de déchets / activités sans valeur ajoutée :

Le gaspillage des compétences humaines – Les dommages aux personnes.
Les défauts – Tout ce qui fonctionne mal et doit être corrigé.
L’inventorisation – Tout ce qui est en attente d’un traitement.
La surproduction – Tout ce qui est en trop / ou trop en avance.
Les Temps d’attente – Tout ce qui tarde à arriver / à se produire engendre de l’inactivité.
Les mouvements – Déplacements humains injustifiés.
Les transports – Déplacements de personnel et de matériel.
Le traitement des déchets – Tout ce qui doit être fait et qui n’ajoute pas de valeur au produit ou au service.

Les deux méthodes interagissent et se renforcent mutuellement, de sorte que les gains en pourcentage de rendement du capital investi (Return On Invested Capital, ROIC), sont beaucoup plus rapides si Lean et Six Sigma sont mises en oeuvre ensemble.

En bref, ce qui caractérise Lean Six Sigma, en dehors de ses composantes propres, c’est avant tout la prise en compte mutualisée des aspetcs qualité et vitesse au profit d’un processus équilibré, lequel permettra à l’organisation de se concentrer sur l’amélioration de la qualité du service tel que définie par le client, au respect des délais convenus.

DMAIC (Define-Mesure-Analyse-Improve-Control)

« définir, mesurer, analyser, innover/améliorer et contrôler »

Utiliser DMAIC pour améliorer les processus de service

Tous les modèles sont faux, mais certains sont utiles. (Box)

Quelques soient les modalités de déploiement des équipes d’amélioration au sein de l’organisation, toutes doivent être informées avec précision de leurs objectifs. C’est ici qu’interviennent les modèles d’amélioration standard tels que DMAIC. Le modèle DMAIC en tant qu’approche structurée et rigoureuse d’amélioration des processus est composé de cinq phases, chaucune étant liée de façon logique aux phases attenantes.

Il existe de nombreuses ressources en ligne décrivant le processus DMAIC. Aussi nous concentrerons-nous ici sur les considérations particulières à l’utilisation du processus DMAIC du Lean Six Sigma dans un environnement de services, y compris les méthodes et les outils les plus pertinents, ainsi que des conseils sur la façon de modéliser les aspects humains de chaque phase.

Définir (Define)
Mesurer (Mesure)
Analyser (Analyse)
Améliorer (Improve)
Contrôler (Control)

Définir (Define)

Au cours de cette première phase, l’équipe et ses sponsors se mettent d’accord sur le projet et ses objectifs. En supposant qu’une ébauche de la charte de projet soit déjà en place, la principale tâche de l’équipe projet durant la phase Définir consistera à réaliser une analyse de ce que le projet devrait accomplir, et d’en confirmer la compréhension avec le(s) sponsor(s). Ils doivent s’entendre sur le problème qui impacte les clients, et sur comment le processus en cours ou les résultats produits ne répondent plus aux besoins , en s’appuyant sur l’avis du client, ou les attentes mesurables du client (Critical To Quality, CTQ).

Les résultats de la phase Définir sont les suivants :

Un énoncé clair de l’amélioration prévue (charte de projet).
Une carte de haut niveau des processus (SIPOC).
Une liste de ce qui est important pour le client (CTQ).
Un meilleur alignement du projet à la stratégie d’entreprise.
Une contribution significative et mesurable au ROIC.

Les outils les plus couramment utilisés au cours de la phase de Définir sont :

La charte de projet
L’analyse des intervenants.
Le schéma FIPEC (schématisation des Fournisseurs, Intrants, Processus, Extrants et Clients d’un processus) (aussi appelé SIPOC en anglais)
L’avis du client.
Le diagramme des affinités.
Le modèle de Kano.
L’arbre CTQ (Critical To Quality, représentation des facteurs clés de succès).

Les sections suivantes fournissent une brève description de ces outils et techniques.

Charte de projet

La charte est un contrat entre la Direction Générale de l’organisation et l’équipe du projet, créé à l’initialisation de ce dernier. Son objectif est de:

Clarifier ce qui est attendu de l’équipe.
Garder l’équipe concentrée sur les objectifs.
Garder le projet et l’équipe alignés sur les priorités organisationnelles.

Analyse des intervenants

Un projet DMAIC exigera un changement fondamental dans les processus. Dans un effort pour atténuer la résistance au changement lorsque l’amélioration est mise en oeuvre, il est crucial d’identifier les parties prenantes dès le démarrage, et d’élaborer un plan de communication pour chacun d’eux. Les intervenants typiques comprennent notamment les managers, le personnel employé dans le processus à l’étude; en amont et en aval : les départements, les clients, les fournisseurs et les finances. Une communication régulière permet d’identifier de meilleures solutions et ainsi d’éviter les pièges.

Schéma SIPOC

Un schéma SIPOC est une carte de processus de haut niveau qui comprend les fournisseurs, les intrants, les processus, les extrants, et les clients. La qualité est évaluée en fonction de la sortie du processus. Elle est améliorée par l’analyse des données d’entrée et des variables de processus. Un exemple de schéma SIPOC est fourni ci-dessous.

SIPOC

Figure 1: Exemple de schéma SIPOC

L’avis du client

L’avis du client est un processus utilisé pour consigner les exigences et les retours du client (interne ou externe) afin d’y répondre par la meilleure qualité possible en termes de service ou de produit. Ce processus est totalement tourné vers la réactivité et l’innovation permanente, afin de s’adapter à l’évolution constante des besoins des clients au fil du temps.

L’avis du client est le terme utilisé pour décrire les besoins exprimés et non-exprimés du client, ainsi que ses exigences. L’avis du client peut être obtenu par différentes pratiques dont notamment : la discussion directe, les entretiens, les enquêtes, les groupes de discussion, les spécifications du client, l’observation, les données de garantie, les rapports de terrain, les cahiers de doléances, etc.

Ces données sont utilisées pour identifier les attributs de qualité indispensables à la fourniture d’un composant ou d’un matériel à intégrer dans le processus ou le produit. L’avis du client est vital à l’organisation pour :

Décider quels produits et services offrir.
Identifier les caractéristiques essentielles et les spécifications de ces produits et services.
Décider où concentrer les efforts d’amélioration.
Obtenir une mesure de référence de la satisfaction de la clientèle en rapport de laquelle l’amélioration sera mesurée.
Identifier les facteurs clés de la satisfaction client.

Liste de produits typiques issus de l’avis du client :

Liste des clients et des segments de clientèle.
Identification des sources réactives et proactives de données pertinentes.
Données verbales ou numériques qui identifient les besoins des clients.
Définit les facteurs clés de succès (Critical To Quality, CTQ).
Spécifications pour chaque exigence CTQ.

Diagramme des affinités

Un diagramme des affinités (parfois dénommé un “KJ”, d’après les initiales du créateur de cette technique, Kawakita Jiro), est un type particulier d’outil de remue-méninges (brainstorming). Un diagramme des affinités peut être utilisé pour :

Rassembler un grand nombre d’idées, des opinions ou des problématiques et regrouper entre eux les éléments qui sont naturellement liés.
Identifier, pour chaque groupe, un concept unique et commun à toutes ses composantes.

Diagramme des affinités

Figure 2: Exemple de diagramme des affinités

Un diagramme des affinités est particulièrement utile lorsque:

Le chaos domine.
L’équipe se noie dans un grand volume d’idées.
Il faut créer de nouveaux paradigmes ou systèmes d’analyse.
Des problématiques ou des thèmes généraux doivent être identifiés.

La construction d’un diagramme des affinités est un processus plus créatif que logique qui encourage la participation de tous, chacun étant encouragé à soumettre ses propres idées qui seront toutes prises en compte.

Modèle de Kano

Développé dans les années 1980 par le professeur Noriaki Kano, le modèle de Kano se fonde sur les concepts de qualité des clients et fournit un système de classement simple qui distingue les attributs essentiels et ceux de différenciation. Le modèle de Kano est un puissant outil de visualisation des caractéristiques du produit et de stimulation du débat au sein de l’équipe de conception. Kano a également produit une méthodologie rigoureuse pour la cartographie des réponses des consommateurs dans le modèle. Les caractéristiques des produits peuvent être classées comme suit:

Seuils / Attributs de base

Les attributs qui doivent être présents pour que le produit soit efficace, et puisse être considéré comme un prix d’entrée. Toutefois, le client restera neutre à l’égard du produit, même avec une meilleure exécution de ces seuils et attributs de base.

Attributs unidimensionnels (performance / linéaire)

Ces caractéristiques sont directement liées à la satisfaction du client. Fonctionnalités accrues et qualité de l’exécution se traduiront par une hausse de la satisfaction. Inversement, une diminution des fonctionnalités aura pour résultante une hausse de l’insatisfaction. Le prix des produits est souvent liée à ces attributs.

Attributs avantageux (incentifs)

Les clients retirent une satisfaction importante d’une fonctionnalité et sont prêts à payer un supplément de prix. Cependant, la satisfaction ne diminuera pas si le produit ne possède pas la fonctionnalité. Ces caractéristiques sont souvent non-attendues par les clients et peuvent être difficiles à établir en fonction des besoins lors de la conception initiale. Elles sont parfois appelés besoins inconnus ou latents.

Un exemple de modèle de Kano est fourni ci-dessous.

Modèle de Kano

Figure 3: Exemple de modèle de Kano

Arbre CTQ (Représentation des facteurs clés de succès)

Le but de la représentation des facteurs clés de succès est de convertir les besoins / les attentes des clients en exigences mesurables à implémenter.

Exemple : Un commerce de détail recevait un nombre important de plaintes de clients et relatives à la politique de garantie. En analysant les données de l’enquête conduite auprès de la clientèle et le développement de l’arbre CTQ, l’entreprise a été en mesure d’identifier les besoins essentiels à la satisfaction. Ces exigences sont devenues de facto la cible d’amélioration de la satisfaction du client. L’entreprise a ainsi éliminé les visites de garantie obligatoires, dès lors optionnelles. Cette décision a permis de restaurer la statisfaction des clients qui déploraient un nombre trop important de visites, tandis que l’ajout d’une visite optionnelle a donné satisfaction à ceux qui avaient une perception contraire. Porter de deux semaines à trois mois le délai pour la planification des visites de garantie a également permis d’éliminer les désagréments causés aux clients à faible disponibilité de temps.

L’entreprise est partie d’un besoin générique et difficile à mesurer (améliorer la satisfaction des client durant le cycle de garantie) et a pu développer des exigences spécifiques et mesurables, pour renforcer et améliorer la satisfaction client.

Arbre CTQ

Figure 4: Exemple d’arbre CTQ (Représentation des facteurs clés de succès)

Mesurer (Mesure)

Un des principaux avantages de Six Sigma repose sur l’exigence d’une approche analytique factuelle et pilotée par les données. La plupart des autres méthodes d’amélioration, y compris Lean, ont tendance à aborder l’amélioration des processus sans avoir collecté suffisamment de données pour comprendre les causes profondes des problèmes. Il en résulte souvent des projets avortés, avec des résultats à court terme ou décevants. Combiner les données avec les connaissances et l’expérience est ce qui distingue fondamentalement l’amélioration véritable du simple bricolage de processus. L’un des objectifs de la phase de mesure est de repérer le lieu ou la source d’un problème aussi précisément que possible par la construction d’une connaissance factuelle des conditions de traitement existantes. Cette connaissance permet de restreindre l’éventail des causes potentielles nécessitant une enquête au cours de la phase d’Analyse. Une part importante de la phase Mesurer consiste à établir un niveau de capacité de base.

Les outils les plus couramment utilisés au cours de la phase de Mesure sont:

Les matrices des priorités.
L’efficacité du cycle de processus.
L’analyse de la valeur de temps.
Les diagrammes de Pareto.
Les cartes de contrôle.
Les diagrammes de production.
L’Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité (Failure Modes and Effect Analysis, FMEA).

Les sections suivantes fournissent une brève description de ces outils et techniques.

Matrice des priorités

La matrice des priorités fournit un procédé de tri d’un ensemble diversifié d’éléments par ordre d’importance. Elle permet également d’identifier l’importance relative de chaque élément en y associant une valeur numérique. Ainsi, un article avec un score de 300 sera beaucoup plus important qu’un second présentant un score de 30, mais ne sera en revanche pas beaucoup plus important qu’un troisième ayant un score de 280. Les éléments sont comparés, évalués en fonction d’un ensemble de critères clés, et les scores pour chaque élément sont ensuite additionnés.

Matrice des priorités

Figure 5: Exemple de matrice des priorités

L’efficacité du cycle de processus

Méthode de calcul permettant de déterminer la quantité de temps à valeur ajoutée en regard du temps total du cycle dans un processus.

Analyse de la valeur de temps

Graphique qui sépare visuellement la valeur ajoutée de temps à l’absence de valeur ajoutée de temps dans un processus.

Diagrammes de Pareto

Vilfredo Pareto, économiste italien au début du siècle, a étudié la distribution de la richesse de différents pays, et en a conclu qu’une minorité relativement stable (environ 20%) contrôlent la grande majorité (environ 80%) de la richesse d’une société. Cette même répartition a été observée dans d’autres domaines, ainsi baptisée l’effet de Pareto.

Diagramme de Pareto

Figure 6: Exemple de diagramme de Pareto

L’effet de Pareto fonctionne à l’identique dans l’amélioration de la qualité : 80% des problèmes découlent généralement de 20% des causes. Les diagrammes de Pareto sont utilisés pour mettre en évidence le principe de Pareto en action, organisant les données de sorte de montrer comment quelques facteurs essentiels peuvent causer la plupart des problèmes qui se manifestent. Concentrer les efforts d’amélioration sur ces quelques problématiques sera gage d’un impact plus rapide et plus mportant , ainsi que d’une rentabilité améliorée, contrairement aux efforts non-dirigés.

Cartes de contrôle

Chaque processus est de naturer à varier. Si vous écrivez votre nom dix fois, vos signatures seront tous semblables, mais aucune ne sera exactement identique aux autres. Il existe une variation inhérente selon des limites prévisibles. Si, alors que vous signez votre nom, quelqu’un pousse votre coude, vous obtenez une modification inhabituelle en raison de ce qu’on appelle une cause « particulière ». Si vous travaillez à la taille de diamants, et que quelqu’un pousse votre coude, la cause particulière peut s’avérer coûteuse. Pour de nombreux processus, il est important de relever les causes spéciales de variation dès qu’elles se produisent.

Carte de contrôle

Figure 7: Exemple de carte de contrôle

Il existe également une cause commune de variation. Considérons un joueur de football. Si il a un bon contrôle, la plupart de ses tirs vont partir dans la direction souhaitée. Il y aura certes quelques variations, malgré tout modérées. S’il perd son sang froid et joue avec empressement les ballons, ses tirs deviendront imprécis; la variation augmente. Il peut ne se produire aucune cause spéciale (pas de vent, pas de changement de ballon), juste l’influence cette cause commune de variation. Le résultat: les passes sont moins précises et le jeu devient moins fluide et moins efficace. Au football, le contrôle est un avantage décisif. Il en va de même dans la plupart des processus : réduire la cause commune de variation permet d’économiser de l’argent.

Heureusement, il existe des cartes simples à utiliser qui facilitent l’identification des causes particulières et communes de variation à l’intérieur d’un processus, appelées cartes de contrôle ou tableaux de Shewhart, d’après le nom de leur inventeur, Walter Shewhart. Il existe de nombreuses sous-espèces de cartes de contrôle qui peuvent être appliquées aux différents types de données des processus les plus classiques.

Toutes les cartes de contrôle possèdent trois composantes de base :

Un axe central, en général la moyenne arithmétique de tous les échantillons tracés.
Des limites supérieures et inférieures de contrôle statistique qui définissent les contraintes de variation de la cause commune.
Des données de performance tracées au fil du temps.

Diagrammes de production

Les diagrammes de production (souvent connus sous le nom de graphiques linéaires en dehors du domaine de gestion de la qualité), permettent de montrer la performance d’un processus dans le temps. Les tendances à la hausse ou à la baisse, les cycles, et les aberrations remarquables peuvent être repérées et donner lieu une enquête plus approfondie. Dans un diagramme de production, sont repésentés en ordonnées les événements, et en abscisses l’un intervalle de temps. Par exemple, le diagramme de production d’un hôpital pourrait tracer le nombre de retards lors des transferts des patients au cours d’une journée ou d’une semaine déterminée. Les résultats pourraient montrer qu’il se produit plus de retards à midi qu’à quinze heures. Analyser ce phénomène pourrait permettre de révéler de potentiels besoins d’amélioration. Les diagrammes de production peuvent aussi être utilisés pour suivre et de vérifier les améliorations déjà été mises en place afin de déterminer leur degré de réussite. En outre, une ligne moyenne peut être ajoutée à un diagramme de production pour mettre en évidence les variations de données par rapport à la moyenne.

Diagramme de production

Figure 8: Exemple de diagramme de production

L’Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité (FMEA)

Les procédures et les outils permettant d’identifier chaque mode de défaillance éventuel d’un processus ou d’un produit sont exploités pour déterminer son effet sur d’autres sous-éléments et / ou sur la fonction souhaitée du produit ou du processus. Le FMEA est également utilisé pour classer et hiérarchiser les causes possibles de défaillance, ainsi que pour développer et mettre en oeuvre les actions de prévention adéquates, en lien avec les responsables chargés de réaliser ces actions.

Analyser (Analyse)

La phase de Mesure a permis l’identification des performances de base du processus. En stratifiant les données à l’intérieur du modèle de performance de référence, il devient possible de localiser l’emplacement ou la source de problèmes par l’élaboration d’une connaissance factuelle des conditions de traitement existantes. La phase d’Analyse a pour objectifs d’étudier les hypothèses sur les causes réelles de problèmes, de confirmer ces hypothèses à l’aide des données, et enfin d’identifier la(les) cause(s) du problème. La(les) cause(s) vérifiée(s) constitueront alors la base des solutions dans la phase Améliorer.

Les outils les plus couramment utilisés dans la phase d’analyse sont les suivants :

La méthode des Cinq pourquoi (5 Whys Analysis).
Le remue-méninges (brainstorming).
Les diagrammes de cause et d’effet (diagramme d’Ishikawa ou diagramme en arêtes de poisson).
Les diagrammes des affinités.
Les cartes de contrôle.
Les diagrammes d’activité.
Les diagrammes de Pareto.
Les analyses de régression.
Les diagrammes de dispersion.

La méthode des Cinq pourquoi (5 Whys Analysis)

La méthode des Cinq pourquoi est une technique de résolution de problèmes permettant de découvrir assez rapidement la cause d’un problème. Son application implique de considérer tout problème en se posant la question : « Pourquoi – qu’est-ce qui a causé ce problème ? »

En posant à plusieurs reprises la question « Pourquoi » (cinq est une bonne règle), il est possible d’isoler les symptômes pour révéler racine du problème. Très fréquemment, la cause originale d’un problème conduira à une autre question, puis à une autre encore. Bien que cette technique soit appelée les Cinq pourquoi, vous pourrez être amenés à répéter la procédure de questionnement un nombre variable et plus ou moins important de fois avant de parvenir à mettre au jour la cause profonde d’un problème.

Exemple d’une analyse des Cinq pourquoi :

Pourquoi est-ce que notre client le plus important est-il mécontent ? Parce que nos bicyclettes ont été livrées en retard le mois dernier.
Pourquoi nos bicyclettes ont-elles été livrées en retard le mois dernier ? Parce que la production a pris du retard.
Pourquoi la production a-t-elle pris du retard? Parce qu’il y a une pénurie de roues.
Pourquoi subisssons-nous une pénurie de roues? Parce qu’un grand nombre de roues a été rejeté pour défaut de qualité.
Pourquoi avons-nous rejeté un si grand nombre de pièces ? Parce que le marché a été conclu avec un fournisseur moins cher dont la production s’avère de qualité inégale.

Remue-méninges (brainstorming)

Le remue-méninges consiste tout simplement à lister tous les idées avancées par un groupe en réponse à un problème donné ou une question. En 1939, une équipe dirigée par Alex Osborn a inventé le terme « remue-méninges ». Selon Osborn, le remue-méninges consiste à utiliser le cerveau de sorte de prendre d’assaut un problème de création et de le faire en mode commando, chaque participant attaquant un même objectif, avec la même audace. La créativité est encouragée en ne permettant qu’aucune idée puisse être évaluée ou discutée jusqu’à ce que tous les participants aient épuisé leur inspiration. Toutes les idées sont ainsi considérées comme légitimes, les plus farfelues étant bien souvent les plus fertiles. Les remue-méninges structurés produisent de nombreuses idées créatives à partir de nimporte quelle question centrale. Bien réalisé, il favorise la propension du cerveau humain pour la pensée latérale et la libre association.

Le remue-méninges aide à répondre à des questions spécifiques telles que:

Quelles sont les opportunités face à nous cette année ?
Quels sont les facteurs limitant la performance dans le département X ?
Que pourrait être la cause du problème Y ?
Que pouvons-nous faire pour résoudre le problème Z ?

Toutefois, un remue-méninges ne peut pas vous aider à identifier avec certitude des causes de problèmes, à classer des idées de façon pertinente, à sélectionnez des concepts clefs, ou à contrôler des solutions.

Diagrammes de cause et d’effet

Diagrammes d’Ishikawa ou diagrammes en arêtes de poisson

Le diagramme de cause et d’effet est une idée originale de Kaoru Ishikawa , pionnier des processus de gestion de la qualité dans les chantiers navals de Kawasaki, et devenu l’un des pères fondateurs de la gestion moderne. Le diagramme de cause et d’effet est utilisé pour explorer toutes les causes réelles ou potentielles (entrées) qui aboutissent à un effet unique (sortie). Les causes sont classées selon leur niveau d’importance ou de détail, résultant en une représentation des relations et de la hiérarchie des événements. Le diagramme de cause et d’effet aide à rechercher des causes, à identifier les domaines où il peut y avoir des problèmes, et à comparer l’importance relative des différentes causes.

Les causes dans un diagramme de cause et d’effet sont souvent organisées en quatre grandes catégories. Bien que ces catégories peuvent être de toutes natures, on retrouve généralement :

La main-d’oeuvre, les méthodes, les matériaux et les machines (recommandé pour la fabrication).
Le matériel, les politiques, les procédures, et le personnel (recommandé pour l’administration et les services).

Ces lignes directrices peuvent être utiles mais ne doivent pas être utilisées si elles limitent le diagramme ou s’avèrent inappropriées. Les catégories utilisées doivent répondre aux besoins identifiés et spécifiques à chaque contexte. Bien souvent, il est possible de créer les branches de l’arbre de cause et d’effet à partir des items tirés des diagrammes des affinités déjà évoqués.

Diagramme de cause et d'effet

Figure 9: Exemple de diagramme de cause et d’effet

Diagrammes d’activité

Les diagrammes d’activité sont des cartes ou des représentations graphiques d’un processus. Les étapes d’un processus sont représentées avec des formes symboliques, et le flux du processus est indiqué par des flèches reliant les symboles. Les programmeurs ont popularisé les diagrammes d’activité dans les années 1960, les ayant utilisé intensivement pour cartographier le comportement des programmes.

Dans les travaux d’amélioration de la qualité, les diagrammes d’activité sont particulièrement utiles pour montrer comment un processus fonctionne réellement ou pourrait fonctionner idéalement. Les diagrammes d’activité peuvent aider à vérifier si les étapes d’un processus sont logiques, à révéler des problèmes ou des interprétations erronées, à définir les limites d’un processus, et à développer une base commune de connaissances à propos d’un processus.

Cartographier un processus conduit souvent à mettre en lumière des redondances, des retards, des impasses et des détours qui seraient autrement passés inaperçus ou simplement ignorés. Mais les diagrammes d’activité ne fonctionnent pas si ils ne sont pas strictement exacts, si les membres de l’équipe ont peur de décrire ce qui se passe réellement, ou si l’équipe est trop éloignée du fonctionnement effectif du processus.

Il existe de nombreuses variétés de diagrammes d’activité, et de nombreux symboles sont à disposition. L’expérience a montré qu’il existe trois types principaux adaptés à presque toutes les situations :

Les diagrammes d’activité de haut niveau ne cartographient que les principales étapes d’un processus dont elles fournissent un bon aperçu :

Digramme d'activité HN

Figure 10: Exemple de diagramme d’activité de haut niveau

- Les diagrammes d’activité détaillés déplient étape par étape tous les événements et les décisions d’un processus :

Diagramme d'activité détaillé

Figure 11: Exemple de diagramme d’activité détaillé

- Les diagrammes de déploiement structuent le diagramme en colonnes, chacune représentant une personne ou un service au sein d’un processus :

Diagramme de déploiement

Figure 12: Exemple de diagramme de déploiement

Analyse de régression

L’analyse de régression est un modèle de prévision statistique qui décrit et évalue la relation entre une variable donnée, généralement appelée la variable dépendante, et une ou plusieurs autres variables dites indépendantes.

Les modèles d’analyse de régression sont utilisés pour aider à prédire la valeur d’une variable par rapport à une ou plusieurs autres variables dont les valeurs peuvent être prédéterminés.

Diagrammes de dispersion

Les nuages de points (également appelés diagrammes de dispersion) sont utilisées pour étudier la relation possible entre deux variables se rapportant à un même événement. Une ligne droite de meilleur ajustement utilisant la méthode des moindres carrés, est souvent incluse.

Diagramme de dispersion

Figure 13: Exemple de nuage de points

Eléments à rechercher dans un nuage de points :

Si les points se regroupent dans une bande allant du coin inférieur gauche au coin supérieur droit, il existe une corrélation positive (si x augmente, y augmente).
Si les points se regroupent du coin supérieur gauche au coin inférieur droit, il ya une corrélation négative (si x augmente, y diminue).
Si l’on trace à présent une ligne droite ou une courbe à travers les données de sorte qu’elle suive aussi fidèlement que possible la dispersion des points. Plus la grappe de points se concentre étroitement autour de la ligne imaginaire de meilleur ajustement, plus la relation qui existe entre les deux variables est forte.
Si il est difficile de déterminer où tracer une ligne, et si les points ne montrent aucun groupement significatif, c’est qu’il n’existe probablement pas de corrélation entre les deux variables.

Améliorer (Improve)

L’unique objectif de la phase Améliorer est de démontrer, à l’appui des faits et des données, que les solutions optées permettent réellement de résoudre le problème. L’organisation apportera des changements dans un processus visant à éliminer les défauts, les déchets et les coûts inutiles inhérents aux besoins du client et tels qu’identifiés lors de la phase Définir. Les outils et les stratégies de la phase Améliorer inclueront des matrices de solution comprenant des solutions de rechange adéquates, l’objet du projet, ainsi que les méthodes de mise en oeuvre des solutions attendues.

Les outils les plus couramment utilisés lors de la phase d’amélioration sont :

Le remue-méninges.
Les diagrammes d’activité.
Les analyses des Modes de Défaillance, de leurs Effets et de leur Criticité (FMEA).
L’analyse des intervenants.
La réduction des temps d’installation.
La gestion des files d’attente pour réduire la congestion et les retards.
La Méthode des cinq S.
Kaizen.

Réduction des temps d’installation

La réduction des temps d’installation est le processus visant à diminuer le temps de passage, par exemple, de la dernière pièce certifiée de la série précédente, à la première pièce certifiée de la série suivante. Comme les activités d’installation n’ajoutent aucune valeur marchande au produit, elles sont par essence sans valeur ajoutée. L’outil pour lutter contre les temps d’installation est la procédure d’installation rapide en quatre étapes. Le principe de cette méthode consiste à éliminer tout ce qui interrompt ou entrave la productivité.

Les étapes suivantes fournissent une description haut niveau de la procédure d’installation rapide en quatre étapes :

Identifier et compiler toutes les activités liées au processus et qui s’inscrivent dans une ou plusieurs des catégories suivantes:
1. Activité qui retarde le démarrage des travaux à valeur ajoutée.
2. Activité qui cause des interruptions au travail à valeur ajoutée.
3. Activité semblable ou identique à une autre tâche au sein du processus.
Tenter de déléguer les tâches causant des interruptions ou des retards : l’objectif est ici de déporter les travaux préparatoires à l’extérieur du flux de processus principal de sorte que l’information et le matériel restent disponibles. L’objectif est d’achever rapidement et exclusivement les travaux à valeur ajoutée.
Rationaliser ou automatiser les tâches causant des interruptions ou des retards et qui ne peuvent pas être déléguées.
Mettre le processus sous contrôle statistique : l’installation n’est pas complète tant que la sortie du processus n’est pas conforme aux spécifications et sous contrôle statistique, ce qui signifie que la quantité de variation dans le temps doit être comprise dans les limites prévisibles de +/- 3 sigma.

Gestion des files d’attente pour réduire la congestion et des retards

Souvent, les congestions se produisent lors des variations excessives de la demande, à l’image des retards dont nous faisons tous l’amère expérience dans les gares et les aéroports lors des grands départs annuels en vacances. Une fois identifiées, il existe principalement deux techniques pour réduire les congestions issues de la variation de la demande de service :

Le Pooling : formation croisée du personnel pour permettre le renforcement de certaines équipes plus exposées lors des périodes de pics de charge par d’autres moins sollicitées. Une chaîne d’hôtels, par exemple, peut être amenée à former son personnel de bureau pour aider à l’enregistrement pendant les périodes de pointe, inattendues ou prévisibles.
Le Triaging : Tri des emplois dans des catégories qui reflètent les différents niveaux d’effort requis. Des schémas types de régimes incluent: un temps de service rapide versus à un temps de service lent, les problèmes de routine versus des problèmes catastrophiques. Une fois les catégories de tri identifiées, il faut ensuite élaborer des stratégies différentes pour faire face à chaque catégorie.

Méthode des cinq S

La Méthode des cinq S correspond au processus de création de la propreté du lieu de travail, et la gestion de la signalétique. Le processus des cinq S comprend cinq étapes :

Ordonner / Sort (ou plus littéralement ôter l’inutile) : Organiser et séparer l’essentiel de l’accessoire.
Ranger / Straighten : Organiser et identifier simplifier l’utilisation.
Dépoussiérer, Découvrir des anomalies / Shine : Nettoyez et chercher des moyens pour maintenir propre.
Rendre évident Standardize : Maintenir et contrôler les 3 premiers S.
Etre rigoureux / Sustain : Maintenir la discipline, respecter les règles et soutenir la motivation.

En éliminant le superflu, en désignant un site pour ce qui reste, et en nettoyant les équipements maintenus, les outils et les dispositifs de stockage, l’encombrement est réduit et les éléments nécessaires sont faciles à localiser. La gestion de la signalétique et de l’environnement visuel implique enfin l’utilisation d’indices visuels appropriés (panneaux de signalisation routière, signaux).

Kaizen

Kaizen est souvent traduit en Occident par processus d’amélioration continue. Certains auteurs justifient le succès concurrentiel du Japon sur le marché mondial par la mise en oeuvre du concept Kaizen dans les entreprises japonaises. Contrairement à la démarche habituelle où l’accent est mis sur les changements révolutionnaires, innovants, sur une base événementielle donc, Kaizen s’applique à mettre en place des changements incrémentiels et ininterrompus. L’accent est donc mis sur l’amélioration en continu et l’importance de tout mettre en oeuvre et à tout moment pour tenter de s’améliorer.

Dans la pratique, Kaizen peut être mis en oeuvre dans les entreprises avec à la clef une amélioration de tous les aspects d’un processus métier, selon une approche étape par étape, tout en développant de façon progressive les compétences des employés, grâce à une formation et une participation renforcée.

Les principes de mise en oeuvre de Kaizen sont :

Les ressources humaines sont l’atout le plus important de la société.
Les procédures doivent évoluer par des améliorations progressives plutôt que des changements radicaux.
L’amélioration doit être basée sur des statistiques / évaluation quantitative de la performance des processus.

Contrôler (Control)

Au cours de la phase Améliorer, la solution est placée à l’essai, et des plans sont élaborés pour l’implémentation à grande échelle. Mettre en place une solution peut permettre de résoudre un problème momentanément, mais les activités de la phase de Contrôle demeurent indispensables pour s’assurer que le problème ne se reproduira pas, et que les nouveaux processus peuvent encore être amélioré au fil du temps.

Les outils les plus couramment utilisés dans la phase de contrôle sont:

Les cartes de contrôle.
Les diagrammes d’activité.
Les graphiques pour comparer l’avant et l’après (comme le diagramme de Pareto).
Les diagramme de contrôle du processus qualité.
La normalisation.

Diagramme de contrôle du processus qualité

Un diagramme de contrôle du processus qualité est un outil permettant de documenter les activités du Plan-Do-Check-Act (PDCA) pour le processus visé. La méthode comporte quatre étapes, chacune entraînant la suivante, le tout visant à établir un cercle vertueux :

Planifier une action
Développer (réaliser)
Contrôler (vérifier) – pour voir à quel point l’action est conforme au plan et …
Agir – à partir de ce qui a été appris.

Si le changement a été un succès, il est conseillé d’intégrer les leçons tirées de l’expérience et les appliquer aux futurs changements. Dans le cas contraire, il est nécessaire de recommencer le cycle avec un nouveau plan.

Normalisation

La normalisation permet une production de qualité de produits et de services sur une base fiable, prévisible et durable. La normalisation consiste à s’assurer que les éléments importants d’un processus sont traités de manière cohérente et efficace. Des modifications sont apportées uniquement lorsque des données montrent qu’une nouvelle alternative serait préférable. Utiliser des pratiques standard permettra de :

Réduire la variation entre les individus ou les groupes et ainsi produire des sorties de processus plus prévisibles.
Sensibiliser les opérationnels et les managers nouvellement intégrés.
Fournir une base pour la formation de nouveaux arrivants.
Fournir une piste pour le traçage des problèmes.
Fournir un moyen de capture et de conservation les connaissances.
Donner la direction en cas de conditions inhabituelles.

Article extrait du site ITIL.FR – Le portail communautaire francophone des Meilleures Pratiques.

Commentaires Fermés

ITIL V3 : Mini-Guide 2010

Filed under: Uncategorized — urbandot @ 13 01 12 04124
Tags: conference itil, conference services informatiques, forum gestion services informatiques, gestion, gestion des incidents, gestion des problèmes, gestion services informatiques, ITIL, itsmf, meilleures pratiques, meilleures pratiques itil, meilleures pratiques itsmf

Article extrait du site ITIL.FR – Le portail communautaire francophone des Meilleures Pratiques.

Samedi 03 Avril 2010 17:36

Sommaire :

Cycle de vie des services

Approche qui prend en compte la stratégie, la conception, la transition, l’exploitation et l’amélioration des services informatiques.

Amélioration Continue des Services
Exploitation de Services
Conception de Services
Stratégie de Services
Transition de Services

R – Responsable
A – Avec l’obligation de rendre des comptes
C – Consulté
I – Informé

Rôle : Ensemble de responsabilités, d’activités et de domaines d’autorité attribués à une personne ou à une équipe. Un rôle est défini eu sein d’un processus. Une même personne ou équipe peut endosser plusieurs rôles.

Processus de contrôle
- Boucle ouverte : le résultat n’influence pas les données de départ.
- Boucle fermée : le résultat influence les données de départ afin de maintenir la qualité.
Processus
- Mesure : Orienté performance – Les responsables mesurent le coût et la qualité ; les praticiens mesurent la durée et la productivité.
- Donne des résultats spécifiques : Chaque résultat peut être identifié et vérifié individuellement.
- Fournit des résultats au client : Communication des résultat au client / à la partie prenante dont il doit satisfaire les attentes.
- Répond à un événement spécifique : Possibilité de remonter jusqu’à l’événement déclencheur.

Cycle de vie des services

SDP : Service Design Package (Package de conception d’un service)
SKMS : Service Knowledge Management System (Système de Gestion des Connaissanaces des Services)

Stratégie de Services

Etablit la stratégie globale des services informatiques et leur gestion.

Stratégie et organisation
Stratégie et technologie
Gestion financière
Gestion du portefeuille de services
Gestion de la demande

Les 4 « P »
Plans / Perspectives / Patterns (Schémas) / Positions
Créer de la valeur pour les clients : V = U + G
Utilité (U) : conforme à l’objectif
L’utilité désigne les effets positifs du service perçus par le client. Le service est rendu conformément aux attentes du client.

Ce que le client obtient

Garantie (G) : en état d’utilisation
La garantie désigne l’assurance pour le client que le service est disponible en temps voulu, avec la performance et la sécurité souhaitées.
Comment le service est fourni
Actifs :

Ressources (Informations / Aplications / Infrastructure / Capital financier)
Capacités (Gestion / Organisation / Capital humain / Capital de connaissance)

Gestion financière : Budget / Comptabilité / Facturation / ROI

Gestion du portefeuille de services : Régit l’investissement dans le gestion des services informatiques de manière dynamique entre les organisations et gère la fourniture de valeur.

Portefeuille des services (Service Portfolio) : Services structurés dans un portefeuille de contrats tout au long du cycle de vie.
Pipeline des services (Service Pipeline) : Services en cours de développement.
Catalogue des services : Sous-ensemble des services disponibles publiés (visibles pour le client).

Gestion de la demande : Comprendre et gérer (influencer) la demande de services et les capacités nécessaires pour la satisfaire.

Basé sur l’activité
Schémas d’activité métier (PBA) : comprendre les activités métier (identifier les pics et les creux de l’activité de certaines unités business).

Packages de service :

Services de base : fournir les résultats fondamentaux
Services de soutien : activer / améliorer
Offres différenciées
Packages de niveaux de service (SLP) : un ou plusieurs SLP constituent un package de service.
Package de service de base : fournir Utilité / Garantie à au moins deux SLP.

Types de fournisseur :

TI (interne)
TII (Fournisseur de service partagés)
TIII (Fournisseur de services externes)

Stratégie de Services

Conception de Services

Conçoit des services informatiques appropriés et innovants (architecture, processus, directives, procédures et documentation), capables de satisfaire les besoins métier d’aujourd’hui et de demain.

Conception du portefeuille
Gestion du catalogue des services
Gestion des niveaux de service
Gestion de la capacité
Gestion de la disponibilité
Gestion de la continuité des services informatiques
Gestion de la sécurité des informations
Gestion des fournisseurs

Les 5 aspects de la Conception de Services :

Définir les solutions (Services nouveaux ou modifiés)
Concevoir les systèmes : Portefeuille et Catalogue de services.
Envisager les architectures technologiques
Définir les processus requis
Elaborer les indicateurs et systèmes de mesure

Les 4 « P »
Personnes / Produits / Partenaires / Processus
Package de conception de service (SDP) : définit tous les aspects des services informatiques tout au long du cycle de vie. Créé pour les nouveaux services, pour les changements majeurs et pour les retraits.

Il comprend :

Exigences du service
Conception du service
Evaluation de la maturité de l’organisation
Plan du cycle de vie du service
Programme du service, Plan de transition du service
Plan opérationnel d’acceptation du service
Critères d’acceptation du service

Gestion du catalogue des services : S’assure de la création et du maintien à jour du catalogue de services par l’utilisation d’information précises et actualisées.

Gestion des niveaux de service : Définir / Négocier / Conclure un accord / Superviser (mesurer) / Rendre compte (revues) / Améliorer

Accords sur les niveaux de service (SLA)
Accords sur les niveaux opérationnels (OLA)
Contrats de sous-traitance (UC)
Fournisseurs de services
Fournisseurs

Gestion de la capacité : Fournit des conseils et des recommandations aux secteurs informatique et métier sur les problèmes de performances et de capacité.

Recherche proactive de solutions économiques pour améliorer les performances :

Gestion de la capacité business (BCM)
Gestion de la capacité des services (SCM)
Gestion de la capacité des composants (CCM)
Modélisation
Dimensionnement des applications

Gestion de la disponibilité : Capacité d’un service, d’un composant ou d’un élément de configuration (CI) à remplir sa fonction au moment souhaité.

Disponibilité des services / Disponibilité des composants
Réactif / Proactif
Cycle de vie étendu des incidents

Conception de Services : Soutient le secteur métier en fournissant des mécanismes de rétablissement appropriés.

Démarrage : Planification / Périmètre / Approche projet
Besoins et stratégie : Analyse d’impact sur le business (BIA) / Evaluation des risques / Stratégie et options
Mise en œuvre : Plans / Rétablissements / Tests / Rôles et responsabilités
Activités récurrentes : Education / Formation / Sensibilisation / Tests / Changements / Revues et audits

Gestion de la sécurité des informations : Aligne la sécurité informatique sur la sécurité métier ; protège les informations.

Confidentialité
Intégrité
Disponibilité

Gestion des fournisseurs : Gère les relations avec les fournisseurs et surveille leur performance afin d’optimiser le rapport entre la valeur générée et le coût.

Négocier et superviser les contrats
Créer une politique fournisseurs
Créer une base de données des fournisseurs et des contrats (SCD)

La conception en action

La conception en action

SAC : Service Acceptance Criteria (Critères d’acceptation d’un service)
SDP : Service Design Package (Package de conception d’un service)
SLR : Service Level Requirement (Exigence de niveau de service)
SLA : Service Level Agreement (Accord sur les niveaux de service)

Transition de Services

Fournit des recommandations pour développer la transformation des nouveaux services ou des services modifiés en services opérationnels.

Planification et support à la transition
Gestion des changements
Gestion des actifs de services et des configurations
Gestion des déploiements et des mises en production
Validation et tests de services
Evaluation
Gestion des connaissances

Système des gestion des connaissances des services (SKMS) : Facilite la prise de décisions éclairées.
Système de gestion des configurations (CMS)
CMDB
Expérience des équipes
Documents
Archives
Compétences : personnel, fournisseurs, utilisateurs

Gestion des changements – S’assure que les changements sont :

Enregsitrés
Evalués
Autorisés
Priorisés
Planifiés
Testés
Réalisés
Documentés
Et revus d’une manière contrôlée

Types de changement : Normal / Urgent / Standard

CAB / ECAB / Autorité de changement
Les 7 « R »

Qui REQUIERE le changement ?
Quelle en est la RAISON ?
Quel RESULTAT est requis ?
Quels sont les RISQUES encourus ?
Quelles RESSOURCES sont nécessaires pour l’effectuer ?
Qui est RESPONSABLE de la construction, des tests et de la réalisation ?
Quelle est la RELATION avec les autres changements ?

DML : Definitive Media Library (bibliothèque des supports définitifs)

Gestion actifs de services et des configurations :
(SACM – Service Asset and Configuration Management)
Fournit un modèle logique de l’infrastructure informatique. Définit et contrôle les composants des services informatiques comme de l’infrastructure, et maintient des enregistrements précis et à jour.

P I C S V – Planifier / Identifier / Contrôler / historique des Statuts / Vérification

Gestion des Connaissances

Gestion des Connaissances

Gestion des Déploiements et des Mises en Production

Le modèles en V

Exploitation de Services

Coordonne la conduite des activités et des processus nécessaires pour gérer et fournir les services aux utilisateurs métier et aux clients selon les niveaux convenus.

Gestion des événements
Gestion des incidents
Exécution des requêtes
Gestion des problèmes
Gestion des accès
Fonctions

La valeur se manifeste dans l’exploitation de service en :

Gérant la technologie utilisée pour gérer et soutenir les services
Conduisant, contrôlant et gérant adéquatement les activités au quotidien
Effectuant un suivi de la performance, évaluant les métriques et collectant systématiquement les données afin de permettre une amélioration continue des services.

Fonction : Concept logique se référant aux personnes et aux mesures automatisées qui permettent l’exécution d’un processus défini, d’une activité ou les deux à la fois.
Groupe : Un certain nombre de personnes qui effectuent des activités similaires.
Equipe : Un groupe plus formel
Département : Une structure d’organisation
Division : Un groupe de départements
Rôle : Un ensemble de comportements ou d’actions effectuées par une personne, un groupe ou une équipe dans un contexte spécifique.

Gestion des événements : Toute occurrence détectable ou dicernable revêtant une importance queconque pour la gestion de l’infrastructure informatique ou la fourniture d’un service informatique ; évaluation de l’impact qu’un écart peut avoir sur les services.
- Types d’événements : Information / Avertissement / Exception
- Types de réponse : Enregistré / Réponse automatique / Alerte / Intervention / Incident / Problème / Changement

Gestion des incidents : « Interruption imprévue ou détérioration d’un service informatique »
- Objectif : rétablir le fonctionnement normal du service le plus rapidement possible.

Exécution des requêtes : demande d’information ou de conseil de la part d’un utilisateur, portant sur un changement standard ou sur l’accès à un service informatique. Il peut s’agir, par exemple, de réinitialiser un mot de passe ou de fournir des services informatiques standard à un nouvel utilisateur.

Auto-assistance (Serviceability) : Fournir aux clients la connaissance leur permettant de rechercher eux-mêmes les solutions à des incidents de routine.

Gestion des problèmes :
- Problème : « la cause inconnue d’un ou de plusieurs incidents »
- Peut être réactive ou proactive
- Problèmes et erreurs connues (KE) (problèmes dont la cause première est connue et pour lesquels une solution de contournement provisoire a été identifiée)
- Informations de gestion
- Revues des problèmes / incidents majeurs
- Prévention des problèmes

Gestion des accès :
- Gestion des droits / de l’identité
- Accorder les droits d’utilisation des services aux utilisateurs habilités
- Interdire l’accès aux personnes non habilitées
- Accès / Identité / Droits
- Demander / Vérifier / Fournir les droits / Monitorer les statuts / Suivre les accès / Retirer

Fonctions :
- Centre de service : types local / central / virtuel (follow-the-sun 24h/24, 7j/7) / spécialisé
- Gestion technique : planifie, met en œuvre et maintient une infrastructure technique stable afin de soutenir les processus métier.
- Gestion des applications : Gère les applications tout au long de leur cycle de vie.
- Gestion des opérations : effectue les activités au quotidien et les procédures nécessaires pour gérer et maintenir l’infrastructure informatique de telle sorte que la fourniture et le soutien des services informatiques respectent les niveaux de services convenus.

S’adapte continuellement aux besoins métier et à la demande.

Amélioration continue des services

S’assure que les processus de gestion de services continuent de soutenir le métier.

Valide les services fournis afin de les maintenir en adéquation avec les évolutions constantes des besoins métier
- Aligne et ré-aligne les services informatiques sur le métier
- Identifie les améliorations à effectuer et réalise

Examine les processus tout au long du cycle de vie des services
- Améliore l’efficacité et l’efficience des processus existants
- Comprend les impacts de coûts
- S’assure que chaque processus comporte des buts, des objectifs et est mesurable.

Pourquoi mesurer ? Valider / Justifier / Orienter / Intervenir
Cycle de Deming : Planifier / Réaliser / Vérifier / Agir

Activités	Processus impliqués
Suivi et collecte de données	Gestion des niveaux de service, Disponibilité, Gestion de la capacité et des incidents, Centre de services, Sécurité, Gestion financière
Mesure des données	Gestion des niveaux de service, Disponibilité, Gestion de la capacité et des incidents, Centre de services, Sécurité
Analyse des données	Gestion des niveaux de service, Disponibilité, Gestion de la capacité et des incidents, Centre de services, Sécurité
Présentation et utilisation des informations	Gestion des niveaux de service, Disponibilité, Gestion de la capacité et des incidents, Centre de services, Sécurité
Mise en œuvre d’actions correctives	Gestion des changements, Gestion des niveaux de service

Le processus d’amélioration en 7 étapes

Le processus d'amélioration en 7 étapes

Outils de gestion de Services

Attention : un outil ne sert à rien si l’on ne sait pas s’en servir.

Outils de soutien à l’activité de transition :

Outils de gestion des applications
Tableaux de bord des services et outils de création de rapports
Outils de Data Mining
Systèmes de mesure et de création de rapports
Outils de test et de gestion des tests
Systèmes de déploiement et outils logistiques

Outils en soutien de l’activité de conception :

Conception de logiciels et de matériels
Conception environnementale
Conception de processus
Conception de données
Gestion du cycle de vie des services

Outils en soutien à l’activité de l’exploitation :

Fonction d’auto-assistance
Moteur de contrôle des processus / flux
Système de gestion des configurations (CMS) vérifié et intégré
Contrôle à distance des postes de travail des utilisateurs
Script de diagnostic
Capacité de création de tableaux de bord et de rapports

Outils pour l’amélioration continue des services :

Gestion des systèmes et des réseaux
Gestion des événements / incidents / problèmes
Demandes de service et exécution des requêtes
Gestion des connaissances
Gestion des performances
Gestion de la sécurité et gestion financière

Processus de sélection d’outil

Processus de sélection d'outil

Article extrait du site ITIL.FR – Le portail communautaire francophone des Meilleures Pratiques.

Commentaires Fermés

Personnaliser la méthode Prince2 selon l’environnement du projet

Filed under: PRINCE2 — urbandot @ 13 01 07 04074
Tags: PRINCE2

Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

Qu’entend-on par personnalisation ?

La méthode PRINCE2 peut être appliquée quelque soit la taille, la complexité, l’étendue et la culture de l’environnement auquel appartient le projet, considéré en tant que programme, ou projet isolé. Ainsi, un projet piloté avec la méthode PRINCE2 peut-il être facilement personnalisé selon son contexte de réalisation.

Il importe avant tout de distinguer :

la personnalisation de PRINCE2 – qui implique d’utiliser la méthode à bon escient lors de toute gestion de projet, en s’assurant de l’apport de ressources en quantités adaptées pour permettre la planification, le contrôle, la gouvernance et l’exploitation des processus et des thèmes ;
de l’adoption de PRINCE2 – qui en tant que telle au sein d’une organisation relève plus de l’implémentation.

Approche générale pour la personnalisation

Certains projets peuvent laisser à penser qu’ils ne nécessitent pas l’emploi de PRINCE2 en totalité, et incitent de fait à des implémentations partielles de la méthode. Il s’agit-là d’une compréhension erronée de PRINCE2, dont la spécificité réside dans sa capacité d’adaptation, à condition de n’en rien sacrifier au moment de son application.

Ainsi, personnaliser PRINCE2 ne consistera jamais à sacrifier des pans quelconques de la méthode, laissant à penser qu’il pourrait s’agir de modules isolés, indépendants les uns des autres, sans que l’omission d’un ou de plusieurs n’affecte ceux restants. PRINCE2 est un maillage complexe d’éléments interdépendants : les thèmes y sont exploités par les processus; les techniques supportent les thèmes; les individus assumant les rôles du projet créent les produits de gestion. Si le praticien omet un élément, la gestion du projet toute entière s’en trouve affaiblie.

Subséquemment, la personnalisation de la méthode consistera bien plus dans l’adaptation de cette dernière aux facteurs externes (tels que les standards d’entreprise à respecter), ainsi qu’à d’autres facteurs liés au projet lui-même (tels que l’échelle du projet). Le but étant d’appliquer un niveau de gestion qui ne surcharge pas le projet, mais au contraire permette un contrôle approprié en fonction des contraintes précitées.

Ne pas personnaliser PRINCE2, c’est s’exposer à une gestion “robotique” des projets, si chaque activité de processus est suivie, et chaque produit de gestion délivré, sans plus de questionnement. Il s’agit-là d’un piège classique de la gestion de projets orientée “modèles”.

Personnaliser PRINCE2 revient donc avant tout à s’interroger sur comment appliquer et utiliser la méthode avec un maximum de légèreté.

Appliquer les principes

Du fait que les principes dans PRINCE2 sont universels, ils seront toujours applicables et appliqués en l’état. Par l’observation desdits principes, le praticien cherche à adapter le thème aux facteurs environnementaux et liés au projet, sans en perdre la valeur la valeur intrinsèque.

Adapter les thèmes

Adapter un thème ne signifie pas nécessairement modifier la méthode. Dans la plupart des cas, les facteurs environnementaux et liés au projet sont incorporés au sein même des stratégies et des contrôles du projet lui-même. Les politiques et les standards d’entreprise ou liés à un programme sont consignés et documentés dans la stratégie de gestion des risques, la stratégie de gestion de la qualité, la stratégie de gestion des configurations, et la stratégie de gestion de la communication.

Ces produits de gestion ont vocation à décrire les procédures à appliquer au projet dès lors qu’elles satisfont aux exigences de l’entreprise ou du programme. Le niveau de contrôle requis influencera la surveillance, les revues et le reporting, en termes de formalisme et de fréquence.

Adopter les termes et le langage de l’organisation

La méthode peut nécessiter d’être aménagée pour y introduire la terminologie de l’entreprise ou du programme. Par exemple, si l’entreprise ou le programme utilise l’expression “investissement occasionnel” plutôt que “cas d’affaire”, il peut être approprié de substituer les termes dans la documentation du projet, à condition toutefois que cela améliore la compréhension.

Adapter les produits de gestion

PRINCE2 fournit des profils de description de produits pour les produits de configuration requérant un usage ou un composition particuliers dans le cadre de leur exploitation par les thèmes et les processus. Au cours de la personnalisation de PRINCE2 , les produits de gestion sont susceptibles d’être adaptés, auquel cas il peut s’avérer nécessaire de modifier leurs descriptions ou de produire des nouveaux modèles plus conformes.

Tous ceux impliqués dans le projet doivent connaître clairement et à tout moment : l’objectif de la gestion des produits, ce qu’elle devrait comporter, et quels sont les critères de qualité à évaluer. Par exemple, au sein d’un environnement commercial, le lot de travaux peut nécessiter d’y inclure le détail des bons de commandes accompagné des conditions de ventes.

Adapter les rôles

La structure d’organisation de PRINCE2 doit être considérée avec attention pour tous les projets. Les profils de description des rôles standards sont fournis dans l’appendice C de l’ouvrage Managing Successfull Projects with Prince2 – OGC, mais il faut s’attendre à ce que ces derniers fassent l’objet d’aménagements pour correspondre mieux aux compétences réelles de chacun, dans le contexte du rôle au sein du projet qu’il se verra attribuer.

Prenons l’exemple d’un projet appartenant à un programme, la responsabilité du plan de revue des bénéfices peut incomber au programme.
Dans ce cas, cette responsabilité devrait être retirée de la description de rôle de l’exécutif.

Adapter les processus

Toutes les activités des processus dans PRINCE2 doivent être réalisées; il s’agit seulement d’intégrer le fait que les responsabilités liées à la réalisation de ces activités peuvent changer (si des rôles ont été adaptés), à l’identique des références aux produits de gestion qui peuvent devoir changer (si des produits de gestion ont été adaptés).

Article extrait du site ITIL.FR – Le portail communautaire francophone des Meilleures Pratiques.

UW7A9PUA5DWM

Commentaires Fermés

15 mai 2010

Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

ITIL V3 : Glossaire des termes, définitions et acronymes - actualisé le 07/05/2010.

Acronyme

24 avril 2010

Bienvenue sur le Blog des Meilleures Pratiques

Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

1. Introduction

2. Les concepts

2.1. La relation client/fournisseur / (Customer/supplier relationship)

2.2. Adapter la méthode

3. Processus de gestion de projet / (Project Management Processes)

3.1. Diriger un projet (DP) / (Directing a Project (DP))

3.2. Élaborer un projet (EP) / (Strating up a Project (SU))

3.3. Initialiser un projet (IP) / (Initiating a project (IP))

3.4. Contrôler une séquence (CS) / (Controlling a stage (CS))

3.5. Gérer la livraison de produits (LP) / (Managing Product Delivery (MP))

3.6. Gérer les limites de séquences (LS) / (Managing Stage Boundaries (SB))

3.7. Clôture de projet (CP) / (Closing a Projet (CP))

3.8. Planifier (PL) / (Planning (PL))

4. Les composants / (Components)

4.1. Le cas d’affaires / (Business Case)

4.2. L’organisation

4.2.1 Le comité de pilotage / (Project Board)

4.2.2. Le directeur de projet / (Executive)

4.2.3. Le responsable des utilisateurs / (Senior User)

4.2.4. Le responsable des fournisseurs / (Senior Supplier)

4.2.5. Le chef de projet / (Project Manager)

4.2.6. Le chef d’équipe / (Team Manager)

4.2.7. L’assurance Projet / (Project Assurance)

4.2.8. Le support de projet / (Project Support)

4.3. Les plans

4.4. Les contrôles / (Controls)

4.5. La gestion du risque / (Management of risk)

4.6. La qualité dans un environnement projet / (Quality in a project environment)

4.7. La gestion des configurations / (Configuration management)

4.8. Le contrôle du changement / (Change Control)

Article extrait du site ITIL.FR – Le portail communautaire francophone des Meilleures Pratiques.

23 avril 2010

Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

Introduction à ITIL et à MOF

Qu’est-ce qu’ITIL ?

Structure principale : Le cycle de vie des services

Composants principaux

Qu’est-ce que MOF ?

Structure principale : le cycle de vie des services IT

Composants principaux

Alignement d’ITIL et de MOF

Différences

Positionnement

Cycle de vie

Les personnes – les processus – la technologie (PPT)

Répartition des phases, des processus et des activités

Planier-Faire-Vérifier-Agir

Article extrait du site ITIL.FR – Le portail communautaire francophone des Meilleures Pratiques.

Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

Introduction

Six Sigma

Lean

Lean Six Sigma

Complémentarité

Six Sigma

Lean

DMAIC (Define-Mesure-Analyse-Improve-Control)

Utiliser DMAIC pour améliorer les processus de service

Définir (Define)

Charte de projet

Analyse des intervenants

Schéma SIPOC

L’avis du client

Diagramme des affinités

Modèle de Kano

Arbre CTQ (Représentation des facteurs clés de succès)

Mesurer (Mesure)

Matrice des priorités

L’efficacité du cycle de processus

Analyse de la valeur de temps

Diagrammes de Pareto

Cartes de contrôle

ITIL V3 : Glossaire des termes, définitions et acronymes -
actualisé le 07/05/2010.