Version allégée du Framework ITIL, ISO/IEC 20 000 couvre un certain nombre de processus de son proche cousin.

En revanche, ISO 20000 est une norme et certifie l'entreprise, là ou ITIL s'attache à certifier les collaborateurs individuellement.

La mise en œuvre d'ISO/IEC 20 000 couvre 5 domaines de processus :

• Processus de Fourniture de Services
• Processus de Gestion des relations
• Processus de Résolution
• Processus de Contrôle
• Processus de Gestion des mises en production

1. Les Processus de Fourniture de Services

Les processus du domaine fourniture de Services (Service Delivery) ont pour objectifs de négocier, négocier et trouver un accord sur les accords de Services actuels. Ils ont par ailleurs pour mission de reporter les résultats de ces activités par rapport aux objectifs fixés.

Le détail de chacun des processus composant ce domaine de processus sont présentés ci-dessous :

1.1. Gestion des niveaux de Services

1.1.1. Objectif

La Gestion des niveaux de Services a pour objectif de définir, trouver un accord, enregistrer et gérer les niveaux de Services.

1.1.2. Missions

• La Gestion des niveaux de Services doit documenter et valider l'ensemble des Services,
• Chacun des Services doit être enregistré avec le SLA associé et les objectifs visés,
• La Gestion des niveaux de Services doit assurer que les contrats de support, les contrats fournisseurs, ainsi que les procédures associées soient validées par toutes les parties concernées,
• Afin d'être maintenus à jour, la Gestion des niveaux de Services doit revoir, avec toutes les parties concernées, les SLA.
• Les SLA doivent être gérés sous le contrôle de la Gestion des changements
  

Afin d'améliorer la Qualité, les niveaux de Services doivent être surveillés/mesurés. Les résultats des mesures doivent être comparés aux objectifs visés par les activités. Tout dépassement de SLA doit faire l'objet d'un rapport et d'une revue afin d'alimenter le plan d'amélioration des Services.

1.1.3. Activités

Le fournir de Services doit produire un catalogue de l'ensemble des Services disponibles pour les clients. Le catalogue est un élément clé de collecte des exigences/attentes clients, et il doit être accessible aux clients et aux équipes internes.

Les SLA doivent être validés (signés), par les clients et les représentants des clients chez le fournisseur. Le contenu du SLA doit être construit sur la base des besoins business et du budget des clients. Les objectifs sur lesquels sont évalués les Services, doivent être mesurables et orientés sur la vision client du Service. Les changements Business peuvent impacter le SLA lors de croissance (externe, interne) ou de réorganisation, le cas échéant le SLA doit être adapté aux nouvelles contraintes du client.

Un SLA est un document non technique, qui doit contenir à minima :

• Une description des Services, les objectifs, les moyens de communication et les rapports associés,
• L'approbation et la période de validité du SLA,
• Les détails de la Gestion financière, telle que la facturation (eg: mensuelle),
• Les obligations et responsabilités du fournisseur de Services,
• Les responsabilités du client,
• Les Services et le soutien aux Services,
• L'impact, l'urgence et la priorité,
• Les heures de Services (de 07h00 à 18h00. Les dates de clôture exceptionnelles, les périodes business critiques, les périodes non couvertes),
• Les limites de capacité (nombre d'utilisateurs concurrent autorisés),
• Les noms des personnes habilitées à agir en cas d'urgence (continuité),
• Les actions à entreprendre en cas d'interruption de Services,
• Les procédures d'escalades et de notification (interne et client),
• Les procédures de gestion des réclamations,
• Les interruptions planifiées et autorisées,
• Les procédures internes,
• Les exceptions possibles dans les SLA,
• Un glossaire.
  

Les SLA spécifiques aux contrats de sous-traitance doivent être identifiés. Chacun des ces contrats doit être documenté et validé dans des OLA ou des UC.

Si vous souhaitez en savoir davantage consultez la rubrique dédiée à la Gestion des niveaux de Service.

1.2. Rapports sur les Services

1.2.1. Objectif

Produire à intervalle planifiés des rapports fiables, précis afin de faciliter la communication et de prévenir les décisionnaires.

1.2.2. Missions

Chacun des rapports de Services doit inclure son nom, son objectif, sa cible (destinataires, utilisateurs) et les sources des données utilisées pour construire le rapport.

Les rapports de Services doivent inclure :

• Les résultats obtenus comparés aux objectifs,
• Les caractéristiques de performance de chaque processus opérationnel, telles que les statistiques de charge (workload) et l'utilisation des ressources.
• Les informations concernant les tendances du Service,
• Les non conformités et problèmes liés aux SLA, aux failles de sécurité,
• Les enquêtes de satisfaction
  

1.2.3. Activités

Les problèmes qui découlent des rapports détaillés des processus, tels que les rapports sur les charges planifiées, peuvent être inclus dans les rapports. Le succès de la gestion des processus dépend de l'utilisation qui sera faite des informations contenues dans les rapports. Les rapports de Services doivent être considérés comme des aides à la décision

Il peut y avoir plusieurs types de rapports :

• Réactif (eg: postmortem),
• Proactifs,
• Planifiés (activités planifiées eg : opération planifiée)
  

La surveillance des Services et les rapports de Services englobent tous les critères mesurables du Service, en fournissant à la fois des analyses sur les mesures actuelles et passées.

1.3. Gestion de la disponibilité et de la continuité

1.3.1. Objectif

S'assurer que les engagements de continuité et de disponibilité contractés avec le client peuvent être atteints à tous les instants.

1.3.2. Missions

Afin de s'assurer que les objectifs de disponibilité et de continuité soient atteints ils doivent être identifiés à partir des plans business, des SLA et de l'évaluation des risques. Les exigences doivent inclure les droits d'accès aussi bien que les temps de réponse.

Les plans de Disponibilité et Continuité doivent être développé, maintenus et testé afin de s'assurer que les exigences soient traitées.

La Disponibilité doit être mesurée et enregistrée. Toute indisponibilité non planifiée doit être investiguée et des actions doivent être entreprises. Pour les cas ou l'indisponibilité est prévisible des actions préventives doivent être mises en œuvre.

1.3.3. Activités

Les objectifs globaux de Disponibilité et Continuité est de contrôler les risques et de maintenir la continuité des processus métiers dans le cas d'un incident mineur ou majeur (crash d'avion).

Les plans de continuité et disponibilité doivent être reliés à toutes les sources d'informations de disponibilité et continuité. Ces plans sont :

• revus et maintenus annuellement à minima,
• communiqués au gestionnaire des changements afin de déterminer l'impact d'un changement sur la disponibilité et continuité,
• testés au regard des besoins métiers,
• disponibles y compris en heure non ouvrées

La Gestion de la disponibilité doit :

• surveiller et enregistrer la disponibilité des composants de Services,
• maintenir les données historiques,
• faire des comparaisons avec les SLA afin d'identifier les non conformités,
• identifier, documenter et revoir les non conformités,
• prédire les besoins futurs en termes de disponibilité

La gestion de la continuité définit :

• le temps maximum acceptable d'indisponibilité,
• le temps maximum acceptable de service en mode dégradé,
• les enregistrements et les maintenances,
• les responsabilités,
• les documents, les données et les outils de sauvegarde en cas de restauration,
• le personnel et les instructions de travail nécessaires à la restauration du service,
• les sauvegardes des documents de continuité sur des espaces sécurisés à distance

La gestion de la continuité de Service prend en compte les dépendances qui existent entre les services et les composants. Avant tout changement (system ou service) les impacts doivent être évalués. Les plans de continuité doivent être communiqués aux processus de support.

Afin de s'assurer que les plans de continuité restent fiables au regard des changements systèmes, processus, de personnel, de besoin business des tests fréquents sont de la plus haute importance.

Toutes les parties prenantes doivent être impliquées dans la réalisation des tests, et leurs résultats doivent être documentés et revus afin d'améliorer les Services.

Si vous souhaitez en savoir davantage consultez la rubrique dédiée à la Gestion de la Disponibilité ou la Gestion de la Continuité.

1.4. Gestion financière (budgétisation & facturation)

1.4.1. Objectif

La gestion financière a pour objectif de réaliser les budgets et de facturer le coût de la prestation de Service.

1.4.2. Missions

Des politiques et des processus clairs doivent être établis pour :

• Budgéter et comptabiliser tous les composants IT, les ressources partagées, les frais généraux, les services externes (fournisseurs), les ressources humaines, les assurances et les licences.
• Répartir les coûts indirects et imputer les couts directs sur les services,
• Autoriser et assurer le contrôle financier

Les coûts doivent être budgétés avec suffisamment de détail afin de faciliter le contrôle financier et la prise de décision.

Le fournisseur de Services doit :

• Surveiller et reporter les coûts par rapport au budget,
• Revoir les prévisions financières,
• Gérer les coûts en conséquences des prévisions

1.4.3. Activités

Les processus de budgétisation et comptabilisation peuvent être externes à la Gestion des Services IT. Quoiqu'il en soit la comptabilité doit enregistrer l'utilisation des ressources financières afin de déterminer les coûts par utilisateur, par unité, par activité. Les rapports comptable peuvent être utilisés pour déterminer l'efficacité des couts pratiqués, construire des modèles de couts.

La politique financière doit déterminer :

• Les objectifs de la budgétisation et de la comptabilité,
• Le niveau de détail,
• Le niveau de détail de la facturation,
• Les variations de couts par rapport au budget afin d'alerter en cas de modification importante,
• Le modèle de cout afin de démontrer le coût de la prestation de services,
• La façon dont seront gérées les variations par rapport au budget.

Le niveau d'investissement de la budgétisation et de la comptabilité doit être basé sur les besoins à la fois du client et du fournisseur. Dans un environnement commercial ces activités peuvent demander beaucoup plus de détail et de profondeur. En interne identifier les couts suffit.

Si vous souhaitez en savoir davantage consultez la rubrique dédiée à la Gestion Financière des Services.

1.5. Gestion de la capacité

1.5.1. Objectif

Le fournisseur de Service doit s'assurer qu'à n'importe quel moment, il possède suffisamment de capacité pour atteindre les objectifs actuels et futurs en termes de demandes de Services

1.5.2. Missions

La Gestion de la Capacité doit produire et maintenir un plan de capacité conforme aux besoins business.

La Gestion de la Capacité doit identifier et appliquer des méthodes, des procédures et des techniques afin de surveiller, ajuster et fournir la capacité adéquate. En outre, la Gestion de la Capacité doit intégrer tous les types de changements, qu'il s'agisse des variations business, des effets de nouvelles technologies, que des changements externes à l'entreprise.

1.5.3. Activités

La Gestion de la Capacité doit fournir suffisamment de capacité pour le stockage et le traitement des données au juste prix.

Afin de maintenir le plan de capacité à jour la Gestion de la Capacité évalue et ajuste le plan annuellement. Les effets dus à des upgrades de Services, à des changements, aux nouvelles technologies/techniques, aux changements externes doivent être évalués et inclus dans le plan de capacité.

Cela doit permettre d'atteindre les engagements de Services contractés et définis dans les SLA. Afin de déterminer la capacité adéquate, les prévisions business et les charges de travail estimées doivent être traduite en exigences.

Si vous souhaitez en savoir davantage consultez la rubrique dédiée à la Gestion de la Capacité.

1.6. Gestion de la sécurité

1.6.1. Objectif

Gérer la sécurité de l'information avec efficience sur l'ensemble des Services.

1.6.2. Missions

La management de l'entreprise, avec l'autorité appropriée, doit approuver la politique Sécurité et doit la communiquer à toutes les parties concernées.

Les contrôles de sécurité doivent implémenter les exigences décrites dans la politique de Sécurité. Ils doivent gérer les risques associés aux services ainsi que gérer les habilitations aux services et systèmes.

Les contrôles de sécurité doivent être documentés, et décrire :

• Les risques sur lesquels portent les contrôles,
• La façon dont s'opèrent la maintenance et les opérations de contrôle,
• Les relations avec les changements mis en œuvre.

Il doit y avoir des procédures qui s'assurent que :

• Les incidents de sécurité sont reportés et enregistrés conformément aux procédures de gestion des incidents,
• Tous les incidents de sécurité sont investigués et des actions de gestion des incidents sont mises en œuvre,
• Les types, le volume et l'impact des incidents de sécurité sont surveillés avec des dispositifs appropriés,
• Les accès externes aux systèmes et services sont basés sur des accords officiels et formels

1.6.3. Activités

La gestion de la Sécurité protège les informations ainsi que les équipements utilisés pour le stockage, la transmission et le traitement de ces informations. La gestion de la Sécurité réalise des contrôles d'accès et se prémunis contre les accès non autorisés aux données.

Les risques sont identifiés, contrôlés. Afin d'atteindre ces objectifs, la politique et les procédures sont écrites pour couvrir tous les services, elles contiennent :

• Les rôles, les responsabilités et qui les exerces,
• Les méthodes pour surveiller et maintenir l'efficacité de la politique de sécurité,
• Les formations et compétences des équipes,
• La disponibilité des experts  capables d'intervenir autour de la gestion des risques et l'implémentation des contrôles,
• Aucun compromis quant à l'efficience des contrôles sur les changements,
• La coopération avec les procédures de la gestion des incidents lors du traitement des incidents de sécurité

Les biens tels que les ordinateurs, ou autres moyens de communication, les documents et les données sont :

• Catégorisés selon leur "criticité" par rapport au service,
• Inventoriés et évalués selon le niveau de protection qu'ils requièrent

Le possesseur de chacun des biens doit être identifié, afin de gérer la Sécurité.

Les risques des biens sont évalués selon:

• Leur nature (dysfonctionnement logiciel, dommages physiques, etc.),
• Selon le retour sur expérience et les similitudes,
• Les impacts potentiels sur le business (information indisponibles dans un progiciel)

L'évaluation des risques doit être réalisée à intervalle réguliers, les résultats de l'évaluation doivent être enregistrés. Maintenir les évaluations des risques pendant les changements permet de les maintenir à jour.

Les enregistrements permettent de fournir au management des informations sur :

• L'efficience de la politique de sécurité et des contrôles opérés sur les biens, l'information et les systèmes,
• Les tendances des incidents de sécurité,
• Les éléments d'entrées de l'amélioration continue

Le fournisseur de Service doit mettre en œuvre des contrôles appropriés pour gérer la sécurité de l'information:

• La politique de sécurité doit être communiquée au personnel par le management,
• Les rôles et responsabilités doivent être définis et attribués,
• Tout le personnel doit être formé et conscient des problèmes de sécurité,
• Les incidents de sécurité sont sous le contrôle de la gestion des incidents,
• L'efficience et les tendances de la sécurité de l'information doivent être documentées

Si vous souhaitez en savoir davantage consultez la rubrique ISO/IEC 27001

2. Les Processus de Gestion des relations

Le Processus de Gestion des relations doivent décrire les deux aspects de la gestion des relations commerciales (client) et fournisseurs.

Clients et fournisseurs peuvent être internes ou externes au fournisseur. Mes relations externes feront l'objet d'un Underpinning contract (UC) alors que les relations internes feront l'objet d'un SLA (service Level Agreement) ou OLA (Organizational Level Agreement).

Les processus de Gestion des relations doivent s'assurer que la satisfaction client est atteinte et que les besoins métiers futurs sont communiqués et compris.

Afin d'établir et maintenir de bonnes relations, commerciales et fournisseurs, les relations doivent être clairement définies et comprises par toutes les parties.

Ces relations doivent définir et permettre un accord sur :

• Les besoins métiers (business),
• La capacité et les contraintes,
• Le périmètre, les rôles et responsabilités dans la relation,
• Identification des parties-prenantes,
• Les contrats,
• La fréquence des communications

2.1. Gestion des relations commerciales

2.1.1. Objectif

Établir et maintenir de bonnes relations entre le fournisseur et le client, basées sur la compréhension du client et de ses objectifs.

2.1.2. Objectif

La Gestion des relations commerciales incluse la revue des Services, et la mesure des réclamations client ainsi que la mesure de la satisfaction client.

Le fournisseur de Services doit identifier et documenter les parties-prenantes et clients des Services.

Ces revues doivent être fournies au fournisseur de Services et aux clients à minima une fois par an et avant et après chaque changement de services. Elles doivent inclure :

• Les changements de périmètre des Services,
• Les SLA et contrats,
• Les besoins actuels et futurs des métiers (business),
• Les indicateurs de performance historiques

Afin de discuter de la performance, des réalisations, des problèmes et des plans d'actions des réunions intermédiaires doivent être organisées. Chacune des réunions doit faire l'objet d'un compte-rendu. Le fournisseur de Services planifie et enregistre toutes les réunions officielles, les problèmes, et s'assure du suivi des plans d'actions.

Le processus de Gestion des relations commerciales doit formaliser une procédure de gestion des réclamations, validée par le client. Les enregistrements des réclamations doivent être analysés périodiquement et la procédure doit inclure :

• La liste des réclamations,
• Le reporting et la clôture de toutes les réclamations,
• Une procédure d'escalade pour les réclamations en suspens

Le fournisseur de Services doit nommer une personne en charge de gérer la satisfaction client et le processus de Gestion des relations commerciales. Un processus doit exister pour obtenir et faire des retours sur les mesures de satisfaction client.

Les résultats de ces retours et des analyses des réclamations doivent être utilisées comme élément d'entrée au plan d'amélioration des Services.

2.1.3. Activités

La satisfaction client doit être mesurée afin que le fournisseur de Services puisse comparer sa performance aux objectifs de satisfaction client, et conformément aux enquêtes de satisfaction réalisées.

Tout changement dans la satisfaction doit être investigué et compris. Les résultats et conclusions des enquêtes doivent être discutés avec le client et doivent donner lieu à une amélioration du Service.

Les retours positifs des clients doivent aussi être documentés et transmis aux équipes de fourniture de Services.

2.2. Gestion des fournisseurs

2.2.1. Objectif

La gestion des fournisseurs a pour objectif de gérer les tiers (fournisseurs) afin de s'assurer de la fourniture de Services de qualité.

2.2.2. Missions

Dans la plus part des cas le fournisseur de Services fait appel à de nombreux fournisseurs, afin d'assurer que les Services sont ajustés sur ses besoins le fournisseur de Service doit gérer les relations, les contras et les Services qu'il livre. Le fournisseur doit posséder des procédures de gestion des fournisseurs documentées et doit nommer un gestionnaire de contrats en charge d'entretenir les relations avec chacun des fournisseurs.

Pour chaque Service et chaque fournisseur (supplier)  le fournisseur de Service doit maintenir :

• Une définition précise des Services, de leur périmètre, des rôles et responsabilité documentées dans les SLA ou dans d'autres documents,
• Les contrats fournisseurs doivent être alignés avec les SLA,
• Les rôles et relations entretenues par les cocontractants et sous-contractants doivent être documentés,
• Les contrats et les changements liés doivent être revus et mis à jour dans les SLA,
• Un processus de gestion des différends contractuels, ainsi que les interruptions prévisibles ou non de Services doit être mis en œuvre,
• La surveillance, la revue et l'enregistrement de la performance par rapport aux objectifs,
• Un processus officiel de gestion des différends,
• Des modifications de contrats gérés par la gestion des changements

La performance des résultats par rapport aux objectifs doit être mesurée et revue. Les actions d'amélioration identifiées par ce processus doivent être enregistrées et servir d'élément d'entrée du plan d'amélioration des services

Quand bien même me fournisseur fait appel a d'autres fournisseurs, c'est lui qui porte la responsabilité de la prestation de Services. Le fournisseur de Service doit apporter la preuve que ses propres fournisseurs s'appuient sur les recommandations ISO 20000.

2.2.3. Activités

Les processus de gestion des différends sont définis dans les contrats, cela inclut le processus de gestion des escalades. Ce processus doit assurer que tous les différends sont enregistrés, investigués, que des actions sont mises en œuvre et qu'ils sont clôturés.

Les contrats doivent inclure des critères de réversibilité dans l'hypothèse d'une fin de contrat prévue ou non.

3. Les Processus de Résolution

Les processus de gestion des incidents et problèmes sont des processus distincts, bien qu'ils soient très liés. La Gestion des incidents est en charge de la restauration du Service aux utilisateurs, alors que la gestion des problèmes traite de l'identification et de l'éradication des causes des incidents.

La gestion des problèmes fournit des solutions de contournement à la gestion des incidents pour leur permettre de restaurer le service en limitant au maximum la durée d'interruption.

3.1. Gestion des incidents

3.1.1. Objectif

Restaurer le Service aussi vite que possible et répondre aux demandes de Services.

3.1.2. Missions

Afin de restaurer le Service, tel que convenu avec le client, des procédures doivent être utilisés afin de minimiser l'impact sur le Service.

Tous les incidents doivent être enregistrés et les procédures doivent définir :

• Les impacts business,
• Les enregistrements et leur priorité,
• La classification, les mises à jour et les escalades,
• La résolution et la clôture officielle

Les incidents "majeurs" doivent être classifiés et gérés conformément à un processus prédéfini. La Gestion des incidents doit maintenir les clients informés de la progression de leurs incidents ou demandes de Services et alerter à l'avance pour les cas ou les SLA ne sont ou ne seront pas respectés.

Toutes les équipes impliquées dans la gestion des incidents doit avoir accès aux informations nécessaires telles que les erreurs connues, les solutions aux problèmes et la CMDB

3.1.3. Activités

Les incidents sont remontés par les utilisateurs ou le personnel IT au service desk et enregistrés de telle façon que les informations contenues peuvent être facilement retrouvées, exploitées et analysées. Les incidents peuvent être détectés par des mécanismes automatisés.

La gestion des incidents doit avoir accès à une base de connaissance à jour, cette base de données contient des informations sur les techniciens spécialisés, les incidents passés, les résolutions apportées, ainsi que les problèmes et erreurs connues qui pourront aider à restaurer les Services aussi vite que possible.

La planification de la résolution des incidents doit prendre en compte :

• La définition d'une priorité basée sur l'impact et l'urgence,
• Les compétences disponibles,
• La communication des statuts des incidents vers les utilisateurs,
• La résolution,
• Les mécanismes d'escalade si nécessaire,
• La mise à jour et la clôture des incidents enregistrés

La définition des incidents majeurs doit être prédéfinie, ainsi que les personnes qui ont l'autorité nécessaire de changer le fonctionnement normal des processus de gestion des incidents et problèmes.

Les incidents majeurs doivent avoir un responsable clairement identifié, en charge de coordonner et contrôler tous les aspects de la résolution. Cela inclut l'escalade et la communication au travers de toutes les équipes impliquées dans la résolution.

Si vous souhaitez en savoir davantage consultez la rubrique dédiée à la Gestion des incidents.

3.2. Gestion des problèmes

3.2.1. Objectif

Minimiser les interruptions du business de manière proactive et en analysant la cause des incidents. La gestion des problèmes est responsable de la clôture du problème.

3.2.2. Missions

La gestion des problèmes prévient, de manière proactive, la récurrence ou la reproduction d'incidents ou d'erreurs connues.

Des procédures doivent être adoptées pour identifier, minimiser, éradiquer l'impact des incidents et problèmes.

Ces procédures doivent définir :

• Les enregistrements et la classification de tous les problèmes,
• La mise à jour des problèmes ouverts,
• L'escalade, la résolution et la clôture de tous les problèmes
  

Pour aller plus loin la gestion des problèmes doit inclure :

• Une revue préventive pour limiter les problèmes (analyse de tendances),
• Le transfert des changements à la Gestion des changements,
• Surveiller, revoir et reporter la résolution des problèmes,
• Fournir une information à jour sur les erreurs connues et les problèmes corrigés à la gestion des incidents,
• Fournir des éléments au plan d'amélioration des Services
  

3.2.3. Activités

Lorsque les investigations ont permis d'identifier la cause de l'incident et une méthode de résolution, le problème est qualifié en erreurs connues. Résoudre l'incident n'implique pas nécessairement que la cause sous-jacente ait été éliminée.

Les erreurs connues ne doivent pas être clôturée jusqu'a ce qu'une solution soit appliquée. Toutes les erreurs connues sont enregistrées dans une base de données à jour afin de permettre la restauration du service en un minimum de temps. Les revues doivent porter sur les problèmes non solutionnés, et sur l'analyse des tendances afin d'alimenter les autres processus, tels que les processus client ou pour la formation du Service Desk.

Les incident et problèmes enregistrés peuvent être fermés lorsque les clients valident que la résolution et que la solution mise en œuvre est conforme au fonctionnement du Service. L'enregistrement doit être logué, et la cause de l'incident catégorisé.

La gestion proactive des problèmes permet une réduction des problèmes et incidents.

La prévention des problèmes peut aller de la prévention d'un incident unique, à des difficultés récurrentes sur une fonctionnalité donnée, et enfin jusqu'à des décisions stratégiques. Ce dernier peut nécessiter des dépenses importantes telles que l'investissement sur un réseau informatique de meilleure qualité. A ce niveau la gestion proactive des problèmes se confond avec la gestion de la Disponibilité.

La prévention des problèmes doit aussi inclure la formation des utilisateurs, et la prévention des incidents liés à un manque de connaissances des utilisateurs.

Si vous souhaitez en savoir davantage consultez la rubrique dédiée à la Gestion des Problèmes.

4.    Les Processus de contrôles

Les processus de Gestion des changements et des Configurations, sont des processus phares du model de processus ISO/IEC 20000. Ces processus permettent au fournisseur de Services de contrôler les composants d'infrastructure et de Services, et de maintenir les informations de configurations à jour.

L'intégrité des informations est la base de la prise de décision du processus de gestion des changements, mais aussi pour les autres processus dans l'Organisation IT.

4.1. Gestion des configurations

4.1.1. Objectif

Définir, identifier et contrôler les composants des Services et des infrastructures, et maintenir l'intégrité des informations de configuration.

Note: La gestion financière des biens n'entre pas dans le périmètre de la gestion des configurations au sens de la norme ISO/IEC 20000.

4.1.2. Missions

La mise en œuvre de la gestion des changements et des configurations nécessitent une approche intégrée dans leur implémentation. La Gestion des configurations doit fournir des informations au processus de Gestion des changements sur l'impact potentiel que peut avoir une demande de changement sur la configuration d'un Service ou d'une infrastructure.

Les caractéristiques définissant les éléments de configuration doivent être documentés dans une politique de gestion des configurations. Les méthodes pour identifier, contrôler, et tracer les composants est fournit par la Gestion des configurations.

Tous les éléments de configurations doivent être identifiés de manière unique, ils doivent inclure une description de leurs caractéristiques fonctionnelles et techniques. La profondeur, autrement le niveau de détail nécessaire à l'enregistrement des composants doit être défini et doit inclure les relations que les éléments de configurations entretiennent entre eux ainsi que la documentation nécessaire à la gestion du Service. La base de données des configurations (CMDB) doit être activement gérée et vérifiée de telle sorte que les données qu'elle contient soit fiables et précises.

Les changements appliqués aux éléments de configuration, tels que les changements ou déplacement de logiciels et matériels doivent être tracés et nécessitent la présence d'enregistrement dans la perspective d'un audit.

Afin de protéger son intégrité, la CMDB doit être maintenue dans un environnement sécurisé, qui permet de gérer les accès non autorisés. Cet environnement doit permettre par ailleurs de fournir les moyens nécessaires en cas de récupération après un sinistre. Enfin cela permet de stocker des copies des masters tels que les logiciels et les documents de support.

Les procédures de contrôles des configurations doivent assurer que l'intégrité des systèmes, des services et des composants de Services sont maintenues.

Les procédures d'audit des configurations doivent inclure :

• Les enregistrements manquants détectés durant l'audit,
• Les plans d'actions et les méthodes associés à leur mise en œuvre,
• Le reporting sur les résultats de l'audit
  

4.1.3. Activités

Un propriétaire doit être affecté à chacun des biens et des éléments de configuration (CI). Le propriétaire s'assure que les mécanismes de protection et de contrôles sont en place, tels que les changements autorisés avant leur implémentation.

Un plan de configuration doit être produit contenant :

• Le périmètre, les objectifs, la politique, les rôles er responsabilités,
• La définition, les enregistrements et les rapports sur éléments de configuration,
• Les exigences de responsabilité, de traçabilité et d'auditabilité. Par exemple, des critères de sécurité liés à la législation ou aux objectifs métiers de l'entreprise,
• Le contrôle des éléments de configuration. Par exemple, le possesseur d'un élément de configuration, les accès, la protection et le contrôle des versions.
  

La liste des éléments qui devraient être stockés dans la base de données des configurations (CMDB) doit inclure :

• Les problèmes et les versions des systèmes et des logiciels et les documentations afférentes. Exemple : Les spécifications des exigences, les rapports de tests, la documentation des versions et les possesseurs des éléments de configuration.
• Les éléments de configuration de base, les configurations matérielles standards,
• Une copie physique et logique des masters,
• Les licences et les composants de sécurité, tels que les firewalls, les médias magnéto-optiques,
• La documentation des services, telle que les SLA,
• Les services de support et moyens généraux, tel que l'alimentation électrique des salles blanches,
• Les relations et dépendances entretenus pas les éléments de configuration
  

Les informations de configuration doivent être maintenues à jour et rendue disponible pour la planification, la prise de décision et la Gestion des changements appliquée aux éléments de configuration. Les rapports de Gestion des configurations doivent être disponibles pour toutes les parties intéressées.

Les rapports doivent contenir les derniers éléments de configurations en date, leur emplacement, les liens qu'ils entretiennent entre eux et l'historique de leurs versions.

Les processus de vérifications et d'audits doivent être planifiés afin de s'assurer que le fournisseur de Services :

• Contrôle ses éléments de configuration, ses masters logiciels et ses licences,
• Protège son capital physique et intellectuel,
• Fournit des preuves que les informations sur les configurations sont intègres, contrôlées, et accessibles,
• Gère les changements, les versions et les environnements conformément aux exigences des clients et utilisateurs
  

Les audits de configuration doivent tenir compte de la performance, des caractéristiques fonctionnelles des documents spécifiques de configuration (audit fonctionnel), ainsi que les vérifications que les éléments de configuration sont conformes aux environnements matériels (audit physique).

Les manquements et non conformités relevées doivent être enregistrées et portées à la connaissance des équipes concernées.

Si vous souhaitez en savoir davantage consultez la rubrique dédiée à la Gestion des Configurations.

4.2. Gestion des changements

4.2.1. Objectif

S'assurer que les changements sont évalués, approuvés, implémentés et revus d'une façon contrôlée.

4.2.2. Missions

Les changements, telles que les nouvelles versions, les mises à jour de versions, les déplacements matériels, ou les changements liés à la mise en œuvre d'une solution dus à des incidents/problèmes, peuvent avoir un impact l'environnement de Services.

Afin de s'assurer que tous les changements sont approuvés, implémentés, et revus de façon contrôlée, la gestion des changements contrôle le processus de tous les changements sur l'infrastructure.

Tous les changements doivent être enregistrés et classifiés (exemple : urgent, majeur, mineur). Le processus de Gestion des changements doit documenter une procédure qui doit inclure :

• Un périmètre défini et documenté des tous les Services et changements d'infrastructures,
• L'évaluation des risques, des impacts et des bénéfices métiers,
• Les procédures de retour arrière en cas d'échec lors de la mise en œuvre d'un changement,
• Les politiques et procédures pour les changements urgents,
• La planification, la surveillance et les rapports sur les changements,
• L'approbation, le contrôle, la planification de l'implémentation d'un changement,
• Les revues du changement après son implémentation (PIR)
  

Les changements enregistrés doivent être analysés régulièrement afin de détecter :

• Si le nombre de changement augmente sensiblement,
• Si certaines catégories de demandes sont fréquentes,
• Si les tendances varient,
• Ou toute information importante.
  

Tous les changements doivent être revus après leur implémentation qu'ils soient correctes ou en échecs.  Les résultats de ces revues doivent alimenter les plans d'amélioration des Services.

Un planning contenant les détails de tous les changements approuvés pour être implémentés, ainsi que les dates de livraisons prévues, doit être maintenu et communiqué à tous les intéressés. Ce planning est le document de référence des changements et des nouvelles versions.

4.2.3. Activités

Les changements planifiés doivent être communiqués à l'ensemble des personnes (client, utilisateur, etc.) pouvant être impactées par l'opération.

Une revue postérieure à l'implémentation doit être réalisée pour tout changement majeur. Cette revue doit inclure :

• Les résultats des changements et si les objectifs ont été atteints,
• La satisfaction client par rapport au changement,
• Les effets non prévus qui auraient pu avoir lieu
  

Les manquements identifiés lors de la revue par le processus de Gestion des Changements doit alimenter le plan d'amélioration des Services.

Si vous souhaitez en savoir davantage consultez la rubrique dédiée à la Gestion des Changements.

5.    Le Processus de Mise en production

Alors que la Gestion des changements est en charge du contrôle des changements, la gestion des mises en production est chargée d'implémenter le changement.

la gestion des mises en production coordonne les activité du fournisseur de Services, des fournisseurs externes et des processus métier afin de planifier et livrer les versions dans l'environnement IT.

5.1. Processus de Mise en production

5.1.1. Objectifs

Fournir, livrer et tracer un ou plusieurs changements dans une version donnée sur l'environnement de production IT. la gestion des mises en production doit être liée à la gestion des changements et des configurations.

5.1.2. Missions

Une bonne planification et gestion est nécessaire pour implémenter avec succès une nouvelle version. Mais aussi pour prévoir les impacts et risques éventuels. A ce titre la gestion des configurations doit collaborer étroitement avec la gestion des mises en production.

La fréquence de validation des changements ainsi que les types de changements doivent être décrit dans une politique acceptée et validée. Cette politique doit contenir :

• Les rôles et responsabilités,
• Les personnes habilitées à autoriser le déploiement d'une nouvelle version, ainsi que les tests et environnements de production,
• Chaque version doit avoir un identifiant unique, ainsi qu'une description, une vérification et une validation,
• La méthode pour déployer plusieurs changements dans une unique version,
• La méthode d'automatisation des distributions, des installations, et des processus de mise en production afin de faciliter l'industrialisation et l'efficience
  

5.1.3. Activités

Le fournisseur de Service doit planifier la livraison de nouveaux services, systèmes, applications et matériels. Les plans de mise en œuvre doivent être approuvés et autorisés par toutes les parties prenantes telles que les clients, les utilisateurs, les équipes de support et de déploiement.

Les plans de mise en œuvre doivent inclure :

• L'identification des liaisons entre les CI,
• La communication, la préparation, la documentation, la formation des clients et des équipes internes,
• La vérification et la validation,
• Les versions,
• La planification et les audits antérieurs au déploiement,
• Les enregistrements des versions, y compris les date et les livrables,
• Les liens avec les demandes de changements (RfC), les erreurs connues et problèmes,
• La méthode dont seront traitées les versions en échecs,
• La communication vers le processus de gestion des incidents
  

Toutes les documentations concernant les nouvelles versions doivent être intégrées à la CMDB et répondent aux critères des CI. Après chaque livraison les CI doivent être mis à jour. La Gestion des Changements doit réaliser une revue postérieure à l'implémentation (PIR).

Les recommandations issues de la revue doivent alimenter le plan d'amélioration des Services.

La construction de version et leur distribution doivent être réalisés de telle manière que l'intégrité du matériel et du logiciel soit maintenu durant l'installation, la réalisation du package d'installation, et le déploiement. Un environnement de déploiement doit être mis en œuvre pour construire, tester, approuver toutes les versions avant leur livraison.

Les versions et distributions sont construites pour :

• Se conformer avec l'architecture système existante, la gestion de Service et les standards internes,
• Identifier les risques afin que des actions d'éliminations des risques soient mises en œuvre,
• S'assurer que la plate-forme cible satisfait au pré requis de la nouvelle distribution,
• Établir que la nouvelle version est complète après son déploiement.
  

Les éléments de sortie de ce processus sont utilisés pour les tests. Ils doivent comprendre les instructions d'installation, les logiciels et matériels installés. Une revue de ces éléments est nécessaire afin de vérifier leur complétude.

Les activités de vérification et d'approbation doivent :

• Vérifier que les environnements de pré production et de production sont identiques,
• S'assurer que la nouvelle version est créée sous le contrôle de la Gestion des configurations,
• Vérifier que les tests ont été réalisés (tests fonctionnels, techniques),
• S'assurer que la nouvelle version satisfait aux exigences du client,
• S'assurer que toutes les étapes de la mise en œuvre ont été validées,
• Vérifier que la plate-forme cible correspond aux pré-requis matériels et logiciels lorsque la nouvelle version est déployée.
  

Si vous souhaitez en savoir davantage consultez la rubrique dédiée à la Gestion des Mises en Production.