ISO/IEC TR 22446:2017
(Main)Information technology - Continual performance improvement of IT enabled services
Information technology - Continual performance improvement of IT enabled services
ISO/IEC TR 22446:2017 establishes a continual performance improvement (CPI) process that supports service management system (SMS) as defined in the ISO/IEC 20000 series. This process ensures successful deployment and service performance criteria fulfilment. This process is based on a predictive performance evaluation method and a related repository. ISO/IEC TR 22446:2017 is not intended to be used as a means of certification and does not add any requirements to those specified in ISO/IEC 20000-1. ISO/IEC TR 22446:2017 does not provide specific criteria for identifying the need for risk analysis, nor does it specify the types of risk analysis techniques that are used to support a particular technology. ISO/IEC TR 22446:2017 does not offer techniques for implementing the continual performance improvement process.
Technologies de l'information — Amélioration continue des performances des services informatisés
ISO/IEC TR 22446:2017 définit un processus d'amélioration continue des performances (CPI) qui enrichit le système de management des services (SMS), au sens de la série de normes ISO/IEC 20000. Ce processus veille au succès des déploiements et au respect des critères de performance du service. ISO/IEC TR 22446:2017 repose sur une méthode prédictive d'évaluation des performances et sur un référentiel dédié. ISO/IEC TR 22446:2017 n'a pas pour but d'être utilisé dans le cadre de la certification et n'ajoute aucune exigence à celles spécifiées dans l'ISO/IEC 20000‑1. ISO/IEC TR 22446:2017 ne propose ni des critères sur la nécessité d'effectuer une analyse de risques, ni des techniques d'analyse des risques permettant de contrôler telle ou telle technologie. ISO/IEC TR 22446:2017 ne propose pas non plus de technique de mise en ?uvre de la méthodologie d'amélioration continue des performances des services informatisés.
General Information
Frequently Asked Questions
ISO/IEC TR 22446:2017 is a technical report published by the International Organization for Standardization (ISO). Its full title is "Information technology - Continual performance improvement of IT enabled services". This standard covers: ISO/IEC TR 22446:2017 establishes a continual performance improvement (CPI) process that supports service management system (SMS) as defined in the ISO/IEC 20000 series. This process ensures successful deployment and service performance criteria fulfilment. This process is based on a predictive performance evaluation method and a related repository. ISO/IEC TR 22446:2017 is not intended to be used as a means of certification and does not add any requirements to those specified in ISO/IEC 20000-1. ISO/IEC TR 22446:2017 does not provide specific criteria for identifying the need for risk analysis, nor does it specify the types of risk analysis techniques that are used to support a particular technology. ISO/IEC TR 22446:2017 does not offer techniques for implementing the continual performance improvement process.
ISO/IEC TR 22446:2017 establishes a continual performance improvement (CPI) process that supports service management system (SMS) as defined in the ISO/IEC 20000 series. This process ensures successful deployment and service performance criteria fulfilment. This process is based on a predictive performance evaluation method and a related repository. ISO/IEC TR 22446:2017 is not intended to be used as a means of certification and does not add any requirements to those specified in ISO/IEC 20000-1. ISO/IEC TR 22446:2017 does not provide specific criteria for identifying the need for risk analysis, nor does it specify the types of risk analysis techniques that are used to support a particular technology. ISO/IEC TR 22446:2017 does not offer techniques for implementing the continual performance improvement process.
ISO/IEC TR 22446:2017 is classified under the following ICS (International Classification for Standards) categories: 03.080.99 - Other services; 35.020 - Information technology (IT) in general. The ICS classification helps identify the subject area and facilitates finding related standards.
You can purchase ISO/IEC TR 22446:2017 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
TECHNICAL ISO/IEC TR
REPORT 22446
First edition
2017-11
Information technology — Continual
performance improvement of IT
enabled services
Technologies de l'information — Amélioration continue des
performances des services informatisés
Reference number
©
ISO/IEC 2017
© ISO/IEC 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2017 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Continual performance improvement of IT enabled services . 3
4.1 Inputs and outputs . 3
4.1.1 Inputs . 3
4.1.2 Outputs . 4
4.2 Process . 6
4.2.1 Description . . . 6
4.2.2 Process activities . 8
5 Lifecycle reliability improvement (LCRI) method .10
5.1 Context .10
5.2 Set of reliability problems .10
5.2.1 Classification .10
5.2.2 Reliability problems .11
5.3 Correlation between gathered information (for problem resolution) .15
5.3.1 Context .15
5.3.2 Risks resulting from transition of new or changed services .16
5.3.3 Probability of occurrence of a production incident .16
6 Continual performance improvement repository (CPIR) .16
6.1 CPIR inputs .16
6.2 CPIR outputs .17
6.3 CPIR benefits .17
7 Improvement to the ISO/IEC 20000 series processes .18
7.1 Improvements .18
7.2 Limits .21
Bibliography .22
© ISO/IEC 2017 – All rights reserved iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www.iso.org/iso/foreword.html.
This document was prepared by ISO/IEC JTC 1, Information technology, Subcommittee SC 40, IT Service
Management and IT Governance.
iv © ISO/IEC 2017 – All rights reserved
Introduction
A key success criterion of the continual performance improvement process is to add value by reducing
performance-based economic risks.
The service management processes described in the ISO/IEC 20000 series and the relationships
between the processes can be implemented in different ways by different organizations. This is because
the nature of the relationship between each organization and their customers, users and interested
parties can influence how the service management processes are implemented.
Service and service component measurement and improvement are important aspects of a service
management system (SMS) as described in the ISO/IEC 20000 series.
Service performance improvement is a key to successful deployment of new or changed services.
Reasons why service performance improvement is of critical importance include:
a) IT enabled services can have multiple interdependencies;
b) service components can be built, controlled, operated or maintained by external parties;
c) service component reliability improvement can be a challenging and a key aspect of service
performance.
Also, from a service performance viewpoint, understanding and predicting successful implementations
of new or changed services can be very challenging.
a) Many organizations offer their services to unknown, heterogeneous and inter-networked
consumers and external organizations (for instance, supply chain of a telecom operator).
b) Ensuring the service performance of each component to the service delivery requirements by
all component providers is essential and should be considered when engaging in improvement
activities. In service performance improvement, all of the components should be considered
together.
c) Intelligent service component reliability improvement can be considered difficult due to the lack of
a generic model. And it is not always linked to wear-out failures. As human and mechanical system
controls are being superseded by intelligent service components, reliability improvement of these
components can become more important to the trustworthiness and dependability of services.
Problem management findings illustrated here in these statements form the genesis of the approach.
a) Root causes of service incidents can be often linked to lack of a consistent implementation of
intelligent service components.
b) The degree of consistent implementations of intelligent service components can be common to all
departments within a given organization.
c) Performance risks can strongly impact service value for any organization. Thus, directly or
indirectly, they are always a subset of economic risks.
d) The resolution of service performance problems is strongly connected to intelligent service
component reliability and service capacity.
e) In an open or cloud environment, due to the complexity of these environments, the analysis of
intelligent service component reliability issues can be a heuristic process.
f) Independent of capacity problems, it is possible to predict service performance from reliability
evaluation of intelligent service components.
© ISO/IEC 2017 – All rights reserved v
Previous statements, cited above, reveal a number of benefits to an organization implementing the
lifecycle reliability improvement (LCRI) approach as a method supporting the continual performance
improvement process. To achieve these benefits:
a) LCRI scores should be viewed as performance-based economic risks;
b) LCRI should be viewed as a way to address intelligent service component reliability challenges;
c) LCRI method and the continual performance improvement repository (CPIR) content are continually
updated, but LCRI principles will not change.
This document is intended to support the ISO/IEC 20000 series by providing guidance that enables
continual performance improvements of IT enabled services in terms of:
a) introducing a set of service performance criteria, based on recurring operational known errors
and costly major incidents (the economic losses can be linked, for instance, with user productivity
or with business sales);
b) applying a quantitative method of evaluating intelligent service components by relating their
reliability and service performance. This provides predictable service “health checks” before and
after deployment and supporting problem resolution processes by verifying service performance
criteria and prioritizing actions mitigating performance-based economic risks;
c) introducing a continual performance improvement repository which can be included in the
configuration management system. The repository can store known errors, “health check”
results and service performance criteria. Thus, it enables the management of this information as
configuration items in the SMS to simplify the exchange of information with existing processes;
d) introducing a “step by step refinement” process which provides the means to improve performance
without wasting time, investments or quality:
1) by defining recurrent “health checks” of the services to verify service performance criteria;
2) by defining simple intermediary steps in order to solve performance problems;
3) by demonstrating how the previous systematic method, the previous repository and the root-
cause analysis (RCA) risk evaluation technique can be combined to provide a heuristically
proven strategy for optimizing deployment success of new or changed services with a low
economic risk.
The aim of performance continual improvement process is to deal with the following recurrent issues:
a) performance expectations, either implicit or expressed too late, that should be taken into account
before the deployment of new or changed service;
b) wasted workload and delay by testing multiple non-deployable releases;
c) inefficient technical disagreements between subject matter experts (SME) of the organization and
interested parties;
d) right or wrong decisions, based on opinions, rather than economic risks;
e) lack of common performance-based culture between the organization and interested parties. For
example, “agile” methodologies are harder to adopt;
f) lack of predictive evaluation controls that contribute to the services’ performance improvement.
This document can also contribute to:
a) capturing relevant information, enabling the ability to qualify the value of incidents and action
plans connected to resolution of performance problems;
b) prioritizing service performance improvement opportunities;
vi © ISO/IEC 2017 – All rights reserved
c) determining opportunities to improve the governance of all the parties (and in doing so, the
documented information and the communication between the parties);
d) simplifying the decision-making, as part of the change and/or incident management processes;
e) improving the service management plan and particularly the service performance policy;
f) defining service performance criteria during design and service transition of new and changed
services, and during maintenance of an existing service;
g) improving and complementing the delivery of services;
h) improving the service monitoring and measurement, based on risk-driven performance
information;
i) improving the content of service reports to include evidence of service “good health.”
The systematic approach described in this document is not dependent upon the intended goals or the
functional architecture of the service components. The automated analysis does not require, as inputs,
any non-performance criteria, or any technique, resource, method or organization needed to obtain
those criteria.
© ISO/IEC 2017 – All rights reserved vii
TECHNICAL REPORT ISO/IEC TR 22446:2017(E)
Information technology — Continual performance
improvement of IT enabled services
1 Scope
This document establishes a continual performance improvement (CPI) process that supports service
management system (SMS) as defined in the ISO/IEC 20000 series.
This process ensures successful deployment and service performance criteria fulfilment.
This process is based on a predictive performance evaluation method and a related repository.
This document is not intended to be used as a means of certification and does not add any requirements
to those specified in ISO/IEC 20000-1.
This document does not provide specific criteria for identifying the need for risk analysis, nor does it
specify the types of risk analysis techniques that are used to support a particular technology.
This document does not offer techniques for implementing the continual performance improvement
process.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1
continual performance improvement repository
CPIR
repository that contains service performance criteria (3.12), LCRI (3.6) scores, known performance
errors, at a given time, having a performance economic risk for the organization, and known related
recommendations to mitigate the risk
Note 1 to entry: It is part of the configuration information system.
3.2
fix
last release that solves, with an acceptable level of performance-based economic risk, a known error
Note 1 to entry: This release modifies at least one service component of a new or changed service.
Note 2 to entry: Depending on the nature of the problem, one or a series of linked requests for change would
be associated with a known error to ensure the fix deployment and the decision-making are consistent. The
decision to deploy the change in several releases depends on the release policy, on the context (e.g. crisis driven
by incident management) and on the request for change content.
© ISO/IEC 2017 – All rights reserved 1
3.3
health check
evaluation of the performance of an IT-enabled service or of the reliability (3.10) of an intelligent service
component (3.5)
Note 1 to entry: This evaluation is compared to previous evaluations or to a set of service performance criteria (3.12).
3.4
heuristic method
any exploratory method of solving problems in which an evaluation is made of the progress towards
an acceptable final result using a series of approximate results, for example by a process of guided trial
and error
[SOURCE: ISO/IEC 2382:2015, 2124041]
3.5
intelligent service component
service component comprised of an execution subcomponent and of a controlling subcomponent
Note 1 to entry: It is capable of making decisions (based on inputs and execution conditions) to achieve its
mission and to adapt its behaviour.
Note 2 to entry: Behaviour adaptations are linked to internal organization (goals are driven by organization’s
changes) or external environment (constraints are driven by technology changes, like the Cloud Computing).
EXAMPLE Water towers, for instance, are now managed by an intelligent service component (via radio and
mobile phone protocols).
3.6
lifecycle reliability improvement
LCRI
risk-oriented method translating intelligent service component (3.5) reliability into service performance,
and service performance into intelligent service component reliability
Note 1 to entry: LCRI method checks a subset of service performance criteria (3.12).
3.7
mistake
human action or inaction that can produce an unintended result
[SOURCE: ISO/IEC 2382:2015, 2123030]
3.8
performance incident
incident whose symptom(s) is(are) related to performance
Note 1 to entry: For instance, trouble ticket associated with resetting a password does not involve performance
incident.
EXAMPLE Service complaints, unfulfilled service performance criteria (3.12).
3.9
performance problem
root cause of performance incident (3.8) or of unfulfilled service performance criteria (3.12)
Note 1 to entry: A root cause of a performance incident is not necessarily a performance problem. For instance,
eligibility criteria to Digital Subscriber Line (xDSL) offers are not performance problems, but they may cause
performance incidents. If the marketing direction of a telecommunication organization promotes offers to non-
eligible customers then, if they want to subscribe, they would encounter a problem. It would be a performance
incident linked to a non-performance problem.
Note 2 to entry: A problem related to the reliability (3.10) of a service component will be named “reliability
problem”.
2 © ISO/IEC 2017 – All rights reserved
Note 3 to entry: The root cause of a service performance problem can be related to the integration of its service
components in addition to the reliability of at least one of those service components.
3.10
reliability
degree to which a system, product or component performs specified functions under specified
conditions for a specified period of time
Note 1 to entry: Adapted from ISO/IEC/IEEE 24765.
Note 2 to entry: Wear does not occur in software. Limitations in reliability are due to faults in requirements,
design and implementation, or due to contextual changes.
Note 3 to entry: Dependability characteristics include availability and its inherent or external influencing factors,
such as availability, reliability (including fault tolerance and recoverability), security (including confidentiality
and integrity), maintainability, durability, and maintenance support.
[SOURCE: ISO/IEC 25010:2011, 4.2.5]
3.11
root-cause analysis
root cause analysis
RCA
determination of a potential problem’s (a risk factor’s) underlying cause or causes
[SOURCE: ISO/IEC/IEEE 24765:2010, 3.2612]
3.12
service performance criterion
acceptable level of a configuration item
Note 1 to entry: Service performance criteria are based on incidents type and not on incidents.
4 Continual performance improvement of IT enabled services
4.1 Inputs and outputs
4.1.1 Inputs
4.1.1.1 Incidents and problems
— Service complaints analysis;
— Data needed to qualify service complaints (kinematics of a service, screenshots);
— Available monitoring data and intelligent service components log files (process errors or mistakes);
— Recurrence of the incidents and problems (in time and in space).
4.1.1.2 Classification of incidents
— Analysis of the root causes, of the business impacts and the frequency of production incidents;
— Validation of the “black-box” known errors (and their fixes) by communities’ leaders (to avoid blame
game between experts).
4.1.1.3 Execution inputs related to LCRI
— Automatic detection of the service processing errors;
© ISO/IEC 2017 – All rights reserved 3
— Dynamical discovery and performance inputs (processing times, response times, throughputs) of
the functions performed by intelligent service components;
— Dynamical discovery of intelligent service component calls to other service components (including
their response times and the load associated);
— Dynamical discovery of calls to other service components correlated to service requests (including
an evaluation of their criticality);
— Detailed monitoring of memory and CPU utilizations, and of connection pools.
4.1.1.4 Parameters inputs related to LCRI
Exhaustive parameters of a predefined set of intelligent service components configuration items, as
required by the “tuning reliability problem”, are listed in Table 1.
NOTE Table 1 connects inputs and activities described in this document.
Table 1 — Inputs
Activities Inputs
Incidents and Classification of LCRI execution LCRI parameters
problems incidents inputs inputs
Root-cause analysis x x
LCRI/tuning x x
LCRI/caching of static
x x
content
LCRI/usage model x
LCRI/response time
x
degradation
LCRI/multiplication of
x
synchronous interfaces
LCRI/error handling x
LCRI/resource utilization x
LCRI/freeze of a service
x
component
LCRI/ “top ten” of DBMS
x
transactions
LCRI/timeouts x x
4.1.2 Outputs
4.1.2.1 Quantitative outputs (“health check” related to service performance criteria)
Unlike the correlation between gathered information, the following quantitative outputs are not used
to solve specific performance problems, but to assess service performance as part of economic risks.
Even when related to the same inputs, these outputs are based on service performance criteria coming
from the CPIR. Correlation is not used to compute them.
They can be based on known errors, service catalogue management process, and incidents’ frequency.
NOTE 1 Known errors are used to classify incidents.
New or change service should use known errors to avoid associated performance problems.
NOTE 2 Service catalogue management process is used to allocate incident and problem priorities.
4 © ISO/IEC 2017 – All rights reserved
NOTE 3 A subset of classified incidents can be associated with main performance risks and therefore with
economic risks. This subset can be used by the organization to calculate the risk assessment score on service
delivery and the risk assessment score on service deployment.
4.1.2.1.1 Reliability risks assessment score on service delivery
This score is based on assessment of intelligent service component economic risks.
The SMS can calculate this score by weighing classified incidents.
Two thresholds are empirically defined. These two thresholds delimit three zones (like the green,
orange and red zones of traffic lights). They can be used to evaluate the service component testing and
maintenance workloads:
— Below the first threshold, any change of the service is very risky (side effects; complex
implementation).
— Between the two thresholds, any change of the service is risky and requires discretion and care to
avoid a degradation of identified risks.
— Beyond the second threshold, any change of the service is low risk.
In case of a new service, reliability risks should be managed through design activities.
NOTE Even though this score is always provided by LCRI method, it is not mandatory. However, it can help
the change management process to prioritize change requests.
4.1.2.1.2 Performance risks assessment score on service deployment
This score is based on the probability of the occurrence of an incident.
The SMS should calculate this score by weighing classified incidents.
Two thresholds are empirically defined. These two thresholds delimit three zones (like the green,
orange and red zones of traffic lights). They can be used as acceptance criteria:
— Below the first threshold, any deployment is very risky (probability of occurrence of an incident is
comprised between one and two per week).
— Between the two thresholds, any deployment is risky (probability of occurrence of an incident is
comprised between one and two per month).
— Beyond the second threshold, any deployment is low risk.
This score should be used to control a fix after the building and testing activities of related service
components releases.
In case of a new or changed service, this predictable score should be used to justify a new plan to
prevent a deployment failure in the operational environment. The plan is enriched by the information
of associated known errors that are provided by the CPIR.
NOTE The risk assessment of deployment failure score is mandatory.
4.1.2.2 Semi-quantitative outputs
Through a step by step refinement approach, the continual performance improvement (CPI) process
and methods provide information allowing the customer, the organization and the interested parties
to translate the quantitative outputs into value. For instance, knowing the cost and the probability of
downtime enables a simple translation of performance risk into value.
NOTE 1 The ability to easily translate risks into value is a key LCRI method feature, as its outputs are easily
understandable, for the decision-making process.
© ISO/IEC 2017 – All rights reserved 5
NOTE 2 The CPI process can strongly benefit the organization and customers to make the LCRI evaluation
economic risk-based and to identify known errors that should be inserted in the CPIR.
4.1.2.3 Qualitative outputs
Solving a performance problem does not require to consider all reliability risks. However:
— LCRI scores can be used to extrapolate “what-if scenarios”, i.e. simulate the impact of new actions
and/or of CPIR’s validated actions before any implementation;
— LCRI scores and “what-if scenarios” can contribute to the release and deployment management
processes as acceptance criteria;
— known errors and service performance criteria can contribute to enrich and unify priority policy of
incident management and problem management processes.
4.2 Process
4.2.1 Description
Globally, there are two sources of service performance issues:
— incidents;
— unfulfilled service performance criteria.
Criteria not related to service performance are out of scope of this document. This document considers
them as constraints.
On the other hand, incidents and unfulfilled service performance criteria are too often not addressed.
Thus, this document is intended to address both, as either condition can impact aspects of service
usage, whether by a single user, or by all users of a given type.
NOTE Unfulfilled service performance criteria management can be a part of the problem management.
Step 1: Identify performance incidents and service performance criteria fulfilment
If service performance criteria are fulfilled and if there is no performance incident identified, the
service will be considered with low performance-based economic risk.
NOTE 1 The CPIR provides service performance criteria for a specific organization.
NOTE 2 The LCRI method evaluates performance-based economic risks.
NOTE 3 Service catalogue management process can support the incident and problem management allocations
of priority. This document uses those allocations of priority.
NOTE 4 By definition, identified performance incident or unfulfilled service performance criteria are not
necessarily linked to performance problem.
Step 2: Identify performance problems
In this step, unfulfilled service performance criteria whose priority is high are translated into
performance problems, and RCA method helps to classify root cause(s) of performance incidents as
performance or non-performance problems.
NOTE 1 In this document, non-performance problems are out of scope. Only performance problems are
addressed.
NOTE 2 The process is stopped if the priority of the unfulfilled service performance criteria is not high.
However, the CPIR is updated with the LCRI scores.
6 © ISO/IEC 2017 – All rights reserved
Actions realized by service components interfaced with the evaluated service component should be
taken into consideration when identifying root cause of incidents.
Service performance criteria apply to almost all intelligent service components, but sometimes
they should be selectively applied to some intelligent service components. It would depend on the
environment, the execution context, or the intelligent service component itself. These unfulfilled
service performance criteria should not be identified as performance problem.
Step
...
RAPPORT ISO/IEC TR
TECHNIQUE 22446
Première édition
2017-11
Technologies de l'information —
Amélioration continue des
performances des services
informatisés
Information technology — Continual performance improvement of IT
enabled services
Numéro de référence
©
ISO/IEC 2017
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO/IEC 2017, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2017 – Tous droits réservés
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Amélioration continue des performances des services informatisés.3
4.1 Éléments d’entrée et éléments de sortie . 3
4.1.1 Éléments d’entrée . 3
4.1.2 Éléments de sortie . 5
4.2 Processus . 7
4.2.1 Description . . . 7
4.2.2 Activités du processus . 9
5 Méthode d’amélioration de la fiabilité au cours du cycle de vie d’un composant de
service (LCRI) .11
5.1 Contexte .11
5.2 Types de problèmes de fiabilité .11
5.2.1 Classement .11
5.2.2 Problèmes de fiabilité .12
5.3 Corrélation entre les données collectées (en vue de la résolution des problèmes) .17
5.3.1 Contexte .17
5.3.2 Risques issus de la phase de transition du service nouveau ou modifié .17
5.3.3 Probabilité d’occurrence d’un incident de production .17
6 Référentiel de l’amélioration continue des performances (CPIR) .17
6.1 Éléments d’entrée du CPIR .18
6.2 Éléments de sortie du CPIR .18
6.3 Bénéfices du CPIR .19
7 Contributions aux processus de la série ISO/IEC 20000 .19
7.1 Améliorations .19
7.2 Limites .22
Bibliographie .23
© ISO/IEC 2017 – Tous droits réservés iii
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes
nationaux de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est
en général confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l'ISO participent également aux travaux.
L'ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www.
iso.org/directives).
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de
brevets reçues par l'ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir le lien suivant: www.iso.org/avant-propos.
Le présent document été élaboré par le Comité technique ISO/TC JTC1, Technologies de l’information,
sous-comité SC 40, Gestion des services IT et gouvernance IT.
iv © ISO/IEC 2017 – Tous droits réservés
Introduction
L’un des critères clefs du processus d’amélioration continue des performances est la création de valeur
permise par la réduction des risques économiques orientés performance.
Les processus de gestion des services décrits dans la série ISO/IEC 20000 et les relations entre les
processus peuvent être mis en œuvre de différentes façons par des organismes différents. En effet, la
nature de la relation entre chaque organisme et ses clients, ses utilisateurs et ses parties intéressées
peut orienter la manière de mettre en œuvre les processus de gestion des services.
La série de normes ISO/IEC 20000 met en évidence l’importance de la mesure et de l’amélioration des
services et de leurs composants au sein d’un système de management des services (SMS).
L’amélioration des performances du service est essentielle au déploiement d’un service nouveau ou
modifié. L’amélioration du service est d’une importance fondamentale, notamment pour les raisons
suivantes:
a) les services informatisés peuvent avoir de multiples interdépendances;
b) les composants de service intelligents peuvent être développés, contrôlés, exploités ou maintenus
par des tiers;
c) l’amélioration de la fiabilité des composants de service peut être un aspect exigeant, mais essentiel,
de la performance du service.
Aussi, du point de vue des performances, comprendre et prédire la réussite de la mise en œuvre d’un
service nouveau ou modifié, peut être très compliqué:
a) nombre d’organismes dispensent leurs services à des clients inconnus, hétérogènes et
interconnectés ou/et à des organismes externes (par exemple, la chaîne d’approvisionnement d’un
opérateur de télécommunications);
b) s’assurer que la performance du service fait partie des exigences de fourniture de services
à satisfaire par le fournisseur de chaque composant de service est une activité essentielle, qu’il
convient de gérer dans le cadre des activités d’amélioration. Il convient que l’amélioration de la
performance du service englobe tous les composants;
c) l’amélioration de la fiabilité d’un composant de service intelligent peut être considérée comme
ardue, à cause de l’absence de modèle générique. De plus, la non-fiabilité ne peut pas être simplement
justifiée par des pannes dues à l’usure. Et comme les composants de service intelligents remplacent
le contrôle humain et mécanique des systèmes, l’amélioration de leur fiabilité peut devenir
essentielle, du point de vue de la confiance et de la sûreté de fonctionnement des services.
La genèse de la méthode repose sur les retours d’expérience de la gestion de problèmes illustrés ci-après:
a) les causes des incidents de service peuvent être liées à un manque de cohérence dans la mise en
œuvre des composants de service intelligents;
b) le degré de cohérence des mises en œuvre des composants de service intelligents peut être commun
à toutes les directions d’un organisme donné;
c) les risques de performance peuvent avoir un impact fort sur la valeur des services de n’importe
quel organisme. Aussi, directement ou indirectement, ils constituent toujours un sous-ensemble
des risques économiques;
d) la résolution des problèmes de performance du service est fortement couplée à la fiabilité des
composants de service intelligents et à la capacité des services;
e) dans un environnement ouvert ou Cloud, très complexe, seul un processus heuristique peut
analyser les anomalies de fiabilité des composants de service intelligents;
© ISO/IEC 2017 – Tous droits réservés v
f) indépendamment des problèmes de capacité, il est possible de prédire la performance du service
par le mesurage de la fiabilité des composants de service intelligents.
Ces retours d’expérience montrent un certain nombre d’avantages, pour un organisme, à ajouter la
méthode d’«amélioration de la fiabilité au cours du cycle de vie d’un composant de service ou lifecycle
reliability improvement» (LCRI) à son processus d'amélioration continue. Pour ce faire:
a) il convient que les scores LCRI soient traduits en risques économiques orientés performance;
b) il convient que la méthode (LCRI) soit considérée comme un moyen pour évaluer la fiabilité des
composants de service intelligents;
c) le contenu de la méthode (LCRI), donc du référentiel (CPIR) est enrichi continûment, contrairement
aux principes de la méthode (LCRI).
Le présent document vise à venir à l’appui de la série de normes ISO/IEC 20000 en fournissant des
orientations permettant l’amélioration continue des performances des services informatisés sur les
plans suivants:
a) en introduisant un ensemble de critères de performance du service, basés sur des erreurs connues,
opérationnelles et récurrentes, et des incidents majeurs coûteux (les pertes économiques peuvent
être liées, par exemple, à la productivité des utilisateurs ou aux ventes commerciales);
b) en mettant en œuvre une méthode quantitative d’évaluation des composants de service intelligents
(informatisés), établissant un lien entre leur fiabilité et les performances du service. Cela fournit
des contrôles techniques prédictifs des services avant et après leur déploiement, renforçant
les procédures de résolution de problème en vérifiant les critères de performance du service, et
donnant la priorité aux actions qui atténuent les risques économiques orientés performance;
c) en introduisant un référentiel dédié à l’amélioration continue des performances intégré au système
d’information des configurations. Ce référentiel peut stocker les erreurs connues, les résultats des
contrôles techniques et les critères de performance du service. Il peut ainsi gérer ces informations
en tant qu’éléments de configuration du SMS, pour simplifier l’échange d’informations entre les
processus;
d) en introduisant un processus de perfectionnement incrémental permettant d’améliorer les
performances le plus rapidement possible tout en optimisant les investissements et la qualité
associés:
1) en définissant des contrôles techniques récurrents des services permettant de vérifier des
critères de performance du service;
2) en définissant une succession d’étapes intermédiaires simples permettant de résoudre des
problèmes de performance;
3) en fournissant une stratégie, heuristiquement prouvée, qui permet de réussir les déploiements
et de minimiser le risque économique des services nouveaux ou modifiés. Cette stratégie
s’appuie sur la méthode et le référentiel précédemment décrits ainsi que sur la technique
d’évaluation des risques par analyse des causes (Root Cause Analysis ou RCA).
Le processus d’amélioration continue des performances vise à aborder les problèmes récurrents
suivants:
a) attentes en termes de performance, exprimées implicitement ou trop tardivement, qu’il convient de
prendre en compte avant le déploiement d’un service nouveau ou modifié;
b) charge et délai perdus à tester de multiples versions dont la mise en production n’est pas
envisageable;
c) désaccords techniques entre les experts de l’organisme et les parties intéressées;
d) décisions, bonnes ou mauvaises, plutôt basées sur des opinions que sur des risques économiques;
vi © ISO/IEC 2017 – Tous droits réservés
e) absence d’une culture commune axée sur la performance, entre l’organisme et les parties
intéressées: par exemple, sans cette adoption la mise en œuvre de la méthodologie «agile» est plus
difficile;
f) absence de contrôle prédictif contribuant à l’amélioration de la performance du service.
Le présent document peut aussi contribuer à:
a) recueillir des informations appropriées pour qualifier la valeur des incidents, et des plans d’action
afin de résoudre les problèmes de performance;
b) déterminer les opportunités d’amélioration prioritaires de la performance du service;
c) déterminer les opportunités d’amélioration de la gouvernance de toutes les parties (donc de leur
communication, ainsi qu’un enrichissement des informations documentées);
d) simplifier la prise de décision, dans le cadre des processus de gestion des changements et/ou des
incidents;
e) améliorer la planification de la gestion des services, et, en particulier, la politique relative aux
performances des services;
f) définir les critères de performance du service pendant les phases de conception et de transition du
service nouveau ou modifié et dans le cadre de la maintenance d’un service existant;
g) améliorer et parfaire le processus de fourniture de services;
h) améliorer la supervision et le mesurage du service par des informations sur les risques économiques
orientés performance;
i) améliorer le contenu des rapports du service en y adjoignant des preuves de «bonne santé» du
service.
La démarche systématique décrite dans le présent document est indépendante de la mission du service
ou de l’architecture fonctionnelle des composants du service. Elle ne prend pas en compte les critères
non liés à la performance comme éléments d’entrée. De plus, elle est indépendante de toute technique,
ressource, méthode ou organisme requis pour les déterminer.
© ISO/IEC 2017 – Tous droits réservés vii
RAPPORT TECHNIQUE ISO/IEC TR 22446:2017(F)
Technologies de l'information — Amélioration continue
des performances des services informatisés
1 Domaine d’application
Le présent document définit un processus d’amélioration continue des performances (CPI) qui enrichit
le système de management des services (SMS), au sens de la série de normes ISO/IEC 20000.
Ce processus veille au succès des déploiements et au respect des critères de performance du service.
Il repose sur une méthode prédictive d’évaluation des performances et sur un référentiel dédié.
Le présent document n’a pas pour but d’être utilisé dans le cadre de la certification et n'ajoute aucune
exigence à celles spécifiées dans l’ISO/IEC 20000-1.
Le présent document ne propose ni des critères sur la nécessité d’effectuer une analyse de risques, ni
des techniques d’analyse des risques permettant de contrôler telle ou telle technologie.
Le présent document ne propose pas non plus de technique de mise en œuvre de la méthodologie
d’amélioration continue des performances des services informatisés.
2 Références normatives
Le présent document ne contient aucune référence normative.
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— IEC Electropedia: disponible à l’adresse http://www.electropedia.org/
— ISO Online browsing platform: disponible à l’adresse https://www.iso.org/obp
3.1
référentiel de l’amélioration continue des performances
continual performance improvement repository
CPIR
référentiel contenant les critères de performance du service (3.12), les scores LCRI (3.6), les erreurs
connues de performance constituant, à un moment donné, un risque économique orienté performance
pour l’organisme, et les recommandations connues associées permettant de limiter le risque
Note 1 à l'article: Il fait partie du système gérant les informations de configuration.
3.2
correctif
dernière version qui résout, avec un niveau acceptable de risque économique orienté performance, une
erreur connue
Note 1 à l'article: Cette version modifie au moins un composant de service d’un service nouveau ou modifié.
Note 2 à l'article: En fonction de la nature du problème, une ou plusieurs séries de demandes de changement sont
généralement associées à une erreur connue afin de garantir la cohérence du déploiement du correctif et ainsi
celle de la prise de décision. La décision de déployer le correctif dans plusieurs versions dépend de la politique de
gestion des versions, du contexte (par exemple, une crise, pilotée par la gestion des incidents) et du contenu de la
demande de changement.
3.3
contrôle technique
évaluation de la performance des services informatisés ou de la fiabilité (3.10) des composants de
services intelligents (3.5)
Note 1 à l'article: Cette évaluation est comparée aux évaluations précédentes ou à un ensemble de critères de
performance du service (3.12).
3.4
méthode heuristique
méthode exploratoire de résolution de problèmes comprenant une évaluation de l’évolution vers un
résultat final acceptable par une succession de résultats approximatifs, par exemple selon un processus
encadré de tâtonnements
[SOURCE: ISO/IEC 2382:2015, 2124041]
3.5
composant de service intelligent
composant de service composé d’un sous-composant d’exécution et d’un sous-composant de contrôle
Note 1 à l'article: Il peut prendre des décisions (à partir des entrées et des conditions d’exécution), pour accomplir
sa mission et pour adapter son comportement.
Note 2 à l'article: Les adaptations du comportement sont liées à l’organisme interne (leurs objectifs proviennent
des changements organisationnels) ou à l’environnement externe (les contraintes proviennent des changements
technologiques, comme l’informatique en nuage ou «cloud computing»).
EXEMPLE Des châteaux d’eau sont, aujourd’hui, gérés par un composant de service intelligent (via des
protocoles radio et de téléphonie mobile).
3.6
amélioration de la fiabilité au cours du cycle de vie d’un composant de service
lifecycle reliability improvement
LCRI
méthode axée sur les risques traduisant la fiabilité d’un composant de service intelligent (3.5)
en performance du service et la performance du service en fiabilité d’un composant de service
intelligent (3.5)
Note 1 à l'article: La méthode LCRI vérifie un sous-ensemble des critères de performance du service (3.12)
3.7
méprise
action ou inaction humaine pouvant produire un résultat inattendu
[SOURCE: ISO/IEC 2382:2015, 2123030]
3.8
incident de performance
incident dont le ou les symptômes sont liés à la performance
Note 1 à l'article: Réinitialiser un mot de passe n’est pas un incident de performance.
EXEMPLE Plaintes de service, ou critères de performance du service (3.12) non satisfaits.
2 © ISO/IEC 2017 – Tous droits réservés
3.9
problème de performance
cause d’un incident de performance (3.8) ou de critères de performance du service (3.12) non satisfaits
Note 1 à l'article: Une cause d’un incident de performance n'est pas nécessairement un problème de performance.
Par exemple, des critères d’éligibilité à des offres xDSL ne sont pas des problèmes de performance, mais ils
peuvent provoquer des incidents de performance. Si la direction marketing d’un organisme de télécommunication
propose des offres à des clients non éligibles, et si ces derniers souhaitent y souscrire, ils pourraient rencontrer
un problème. Il s’agirait alors d’un incident de non relié à un problème de performance.
Note 2 à l'article: Un problème concernant la fiabilité (3.10) d’un composant de service est appelé «problème de
fiabilité».
Note 3 à l'article: La cause d’un problème de performance du service peut également être liée à l’intégration de
ses composants de service (en plus de la fiabilité d’au moins un de ses composants de service).
3.10
fiabilité
mesure de la performance d’un système, d’un produit ou d’un composant, pour une fonction, et dans des
conditions et une période de temps spécifiées
Note 1 à l'article: Adapté de l’ISO/IEC/IEEE 24765.
Note 2 à l'article: Les logiciels ne sont pas concernés par l’usure. Les limitations en matière de fiabilité sont dues à
des défaillances concernant les exigences, la conception et la mise en œuvre ou à des modifications contextuelles.
Note 3 à l'article: Les caractéristiques de sûreté du fonctionnement incluent la disponibilité et les facteurs
inhérents ou externes qui la conditionnent, tels que la disponibilité, la fiabilité (y compris la tolérance aux
défaillances et la possibilité de récupération), la sécurité (y compris la confidentialité et l’intégrité), la
maintenabilité, la durabilité et la logistique de maintenance.
[SOURCE: ISO/IEC 25010:2011, 4.2.5]
3.11
analyse des causes
root-cause analysis
root cause analysis
RCA
détermination de la ou des causes sous-jacentes à un problème potentiel (facteur de risque)
[SOURCE: ISO/IEC/IEEE 24765:2010, 3.2612]
3.12
critère de performance du service
niveau acceptable d’un élément de configuration
Note 1 à l'article: Les critères de performance du service reposent sur des familles d’incidents, non sur les
incidents.
4 Amélioration continue des performances des services informatisés
4.1 Éléments d’entrée et éléments de sortie
4.1.1 Éléments d’entrée
4.1.1.1 Incidents et problèmes
— Analyse des plaintes liées au service;
— Données nécessaires à la qualification de plaintes liées au service (cinématique d’un service,
captures d’écran);
© ISO/IEC 2017 – Tous droits réservés 3
— Données disponibles de supervision et fichiers journaux des composants de service intelligents
(erreurs de processus ou méprises);
— Récurrence des incidents et des problèmes (dans le temps et dans l’espace).
4.1.1.2 Familles d’incidents
— Analyse des causes des incidences financières et de la fréquence des incidents de production;
— Validation des erreurs connues de type «boîte noire» (et des correctifs associés) par des experts
référents (pour éviter les débats d’experts des domaines).
4.1.1.3 Éléments d’entrée, liés à LCRI, dépendant de la sollicitation d’un composant de service
— Détection automatique des erreurs de fonctionnement du service;
— Découverte dynamique et mesures de performance (temps de traitement, temps de réponse, débit
transactionnel) des fonctions exécutées par les composants de service intelligents;
— Découverte dynamique des appels, par les composants de service intelligents, aux autres composants
de service (y compris leur temps de réponse et la charge associée);
— Découverte dynamique des appels aux autres composants de service, en fonction de la charge (dont
une mesure de leur criticité);
— Supervision détaillée de l’utilisation de la mémoire, du CPU, et des pools de connexions.
4.1.1.4 Éléments d’entrée, liés à LCRI, dépendant de la configuration d’un composant de service
Les paramètres exhaustifs d’un ensemble prédéfini d’éléments de configuration des composants de
service intelligents, tels que requis pour le problème de fiabilité de type «paramétrage ou tuning», sont
listés dans le Tableau 1.
NOTE Le Tableau 1 associe les éléments d’entrée et les activités décrites dans le présent document.
Tableau 1 — Éléments d’entrée
Éléments d’entrée
Éléments d’entrée Éléments d’entrée
liés à LCRI, dépen- liés à LCRI, dépen-
Activités
Incidents et Familles
dant de la sollicita- dant de la configu-
problèmes d’incidents
tion d’un composant ration d’un compo-
de service sant de service
Analyse de causes (RCA) x x
LCRI/ Paramétrage («tuning») x x
LCRI/Mise en cache des contenus
x x
statiques
LCRI/Modèle d’usage x
LCRI/Dégradation des temps de
x
réponse
LCRI/Multiplication des inter-
x
faces synchrones
LCRI/Traitements des erreurs x
LCRI/Utilisation des ressources x
4 © ISO/IEC 2017 – Tous droits réservés
Tableau 1 (suite)
Éléments d’entrée
Éléments d’entrée Éléments d’entrée
liés à LCRI, dépen- liés à LCRI, dépen-
Activités
Incidents et Familles
dant de la sollicita- dant de la configu-
problèmes d’incidents
tion d’un composant ration d’un compo-
de service sant de service
LCRI/Gel d’un composant de
x
service
LCRI/ «top dix» des transac-
x
tions DBMS
LCRI/Délais d’attente «Timeouts» x x
4.1.2 Éléments de sortie
4.1.2.1 Éléments de sortie quantitatifs (contrôles techniques associés aux critères de
performance du service)
Contrairement à la corrélation entre les données recueillies, les éléments de sortie quantitatifs suivants
ne servent pas à résoudre des problèmes de performance spécifiques, mais à évaluer la performance
du service en tant que partie des risques économiques. Ces éléments de sortie ne sont pas calculés
par corrélation même s’ils utilisent les éléments d’entrée recueillis. Ils sont basés sur les critères de
performance du service qui sont stockés dans le CPIR.
Ils peuvent s’appuyer sur les erreurs connues, sur le processus de gestion du catalogue des services
ainsi que sur la fréquence des incidents.
NOTE 1 Les erreurs connues servent à classer les incidents.
Il convient qu’un service nouveau ou modifié s’appuie sur les erreurs connues, pour éviter les problèmes
de performance associés.
NOTE 2 Le processus de gestion du catalogue des services est utilisé pour attribuer des priorités aux incidents
et aux problèmes.
NOTE 3 Un sous-ensemble des familles d’incidents peut être couplé aux principaux risques de performance,
et donc aux risques économiques associés. L’organisme peut utiliser ce sous-ensemble pour calculer le score
d’évaluation des risques liés à la fourniture du service et le score d’évaluation des risques liés au déploiement du
service.
4.1.2.1.1 Score d’évaluation des risques de fiabilité liés à la fourniture du service
Ce score est basé sur l’évaluation des risques économiques des composants de service intelligents.
Le SMS peut calculer ce score à partir d’une pondération des familles d’incidents.
Deux seuils sont définis de façon empirique. Ils délimitent trois zones (comme les feux vert, orange
et rouge des feux de circulation). Ils peuvent servir à évaluer la charge de test et de maintenance des
composants de service:
— en dessous du premier seuil, tout changement du service est très risqué (effets de bord, complexité
de mise en œuvre);
— entre les deux seuils, tout changement du service est risqué, et exige vigilance et attention pour
éviter la dégradation des risques identifiés;
— au-delà du deuxième seuil, tout changement du service est peu risqué.
© ISO/IEC 2017 – Tous droits réservés 5
Dans le cas d’un nouveau service, il convient de gérer les risques de fiabilité dès la phase de conception.
NOTE Même si ce score est toujours fourni par la méthode LCRI, il n’est pas obligatoire. Il peut cependant
aider le processus de gestion des changements à déterminer l’ordre de priorité pour les demandes de changement.
4.1.2.1.2 Score d’évaluation des risques de performance liés au déploiement du service
Ce score est basé sur la probabilité d’occurrence d’un incident.
Il convient que le SMS calcule ce score en pondérant les familles d’incidents.
Deux seuils sont définis de façon empirique. Ils délimitent trois zones (comme les feux vert, orange et
rouge des feux de circulation). Ils peuvent servir de critère d’acceptation:
— en dessous du premier seuil, tout déploiement est très risqué (probabilité d’occurrence d’un incident
de production comprise entre un et deux par semaine);
— entre les deux seuils, tout déploiement du service est risqué (probabilité d’occurrence d’un incident
de production comprise entre un et deux par mois);
— au-delà du deuxième seuil, tout déploiement du service est peu risqué.
Il convient d’utiliser ce score pour contrôler un correctif à la fin des phases de conception et de test des
versions des composants de service.
Dans le cas d’un service nouveau ou modifié, il convient d’utiliser ce score prédictif pour justifier un
nouveau plan de prévention du risque de dysfonctionnement après mise en production. Les informations
des erreurs connues associées complètent le plan. Elles sont extraites du CPIR.
NOTE Ce score est obligatoire.
4.1.2.2 Éléments de sortie semi-quantitatifs
Grâce à une approche de perfectionnement incrémental, le processus d’amélioration continue des
performances (CPI) et ses méthodes fournissent des informations permettant au client, à l’organisme
et aux parties intéressées de traduire les éléments de sortie quantitatifs en valeur. Par exemple, la
connaissance du coût et de la probabilité d’une panne permet de traduire simplement le risque de
performance en valeur.
NOTE 1 L’aptitude à traduire facilement des risques en valeur est une fonction essentielle de la méthode LCRI,
du fait que ses éléments de sortie sont facilement utilisables pour la prise de décision.
NOTE 2 Les apports du processus d’amélioration continue des performances peuvent être importants pour
l’organisme et ses clients, car ils permettent d’évaluer des risques économiques (évaluation LCRI) et d’identifier
les erreurs connues qu’il convient d’insérer dans le CPIR.
4.1.2.3 Éléments de sortie qualitatifs
Résoudre un problème de performance n’impose pas de considérer tous les risques de fiabilité.
Cependant:
— les scores LCRI peuvent servir à extrapoler des scénarios simulant l’effet des actions, nouvelles
et/ou validées (et stockées dans le CPIR), avant de décider de les mettre en œuvre;
— les scores LCRI et les scénarios de simulation peuvent être des critères d’acceptation et ainsi
alimenter le processus de gestion des mises en production et de leur déploiement;
— les erreurs connues et les critères de performance du service peuvent contribuer à parfaire, et
à unifier, les politiques d’attribution de priorités des processus de gestion des incidents et des
problèmes.
6 © ISO/IEC 2017 – Tous droits réservés
4.2 Processus
4.2.1 Description
Globalement, il existe deux sources aux écarts de performance de service:
— les incidents;
— les critères de performance du service non satisfaits.
Les critères non liés à la performance du service ne relèvent pas du domaine d’application du présent
document. Ils sont considérés comme des contraintes.
Par ailleurs, les incidents et les critères de performance du service non satisfaits sont trop souvent
inexploités. Le présent document est destiné à traiter ces deux paramètres, car chacun d’eux peut
affecter un ou plusieurs aspects de l’usage du service, pour un utilisateur ou pour tous les utilisateurs
d’un type donné.
NOTE La gestion des critères de performance du service peut faire partie de la gestion des problèmes.
Étape 1: Identifier les incidents de performance et les critères de performance non satisfaits
Si les critères de performance du service sont satisfaits, et si aucun incident de performance n’est
identifié, le risque économique orienté performance est considéré comme faible.
NOTE 1 Le CPIR fournit des critères de performance du service pour un organisme donné.
NOTE 2 La méthode LCRI évalue les risques économiques orientés performance.
NOTE 3 Le processus de gestion du catalogue des services peut affiner l’attribution des priorités des processus
de gestion des incidents et des problèmes. Ce document utilise ces attributions de priorités.
NOTE 4 Par définition, les incidents de performance ou les critères de performances du service non satisfaits
identifiés ne sont pas nécessairement liés à un problème de performance.
Étape 2: Identifier les problèmes de performance
À ce stade, les critères de performance du service non satisfaits ayant une priorité élevée sont traduits
en problèmes de performance. La méthode RCA contribue à la détermination des causes d’un incident
de performance en problèmes de performance.
NOTE 1 Le présent document ne considère que les problèmes de performance. Les autres problèmes sont en
dehors de son domaine d’application.
NOTE 2 Le processus est arrêté si la priorité attribuée aux critères de performance du service non satisfaits
est faible. Les scores LCRI sont néanmoins insérés dans le CPIR.
Il convient que l’identification de la cause des incidents prenne en compte les interactions entre les
composants de service interfacés et le composant de service évalué.
Les critères de performance du service s’appliquent directement à presque tous les composants
de service intelligents; mais, parfois, en fonction du l’environnement, du contexte d’exécution ou
du composant de service intelligent lui-même, il convient de les appliquer de façon sélective. Il
est recommandé de ne pas identifier les critères de performance exclus comme des problèmes de
performance.
Étape 3: Identifier les erreurs relatives aux problèmes de performance et spécifier les
recommandations permettant d’atténuer les risques économiques orientés performance
associés
Si un problème de performance est lié à une ou plusieurs causes déjà présentes dans le CPIR, toutes les
recommandations associées sont alors sélectionnées.
© ISO/IEC 2017 – Tous droits réservés 7
Si une cause n’est pas déjà présente dans le CPIR, un expert du domaine concerné doit identifier la ou les
causes et spécifier les recommandations.
NOTE 1 Des experts de l’organisme et/ou des parties intéressées peuvent être requis pour identifier les causes.
NOTE 2 Une recommandation extraite du CPIR constitue un cas de réutilisation d’une solution éprouvée. La
mise en œuvre du plan d’action correspondant est donc souvent rapide, et le risque associé est toujours faible.
NOTE 3 La mise en œuvre d’une recommandation extraite du CPIR ne nécessite pas obligatoirement un
changement d’un composant de service.
NOTE 4 Le CPIR est actualisé sur la base des problèmes de performance des composants de service dont les
causes sont des critères de performance du service non satisfaits. Les erreurs d’usage en sont exclues.
Étape 4: Qualifier le plan d’action
Le plan d’action est complété par la priorité attribuée, puis finalement par les composants de service à
modifier.
Si aucun composant de service n’est à modifier, et si toutes les recommandations sont extraites du CPIR,
il convient de ne pas mettre en œuvre le plan d’action dans un correctif.
Si au moins un composant de service est à modifier, il convient que le plan d’action soit mis en œuvre
dans un correctif.
Si aucun composant de service n’est à modifier, et si certaines recommandations ne sont pas extraites
du CPIR, il est alors recommandé à l’organisme de décider s’il convient de mettre en œuvre le plan
d’action dans un correctif. Il base alors sa décision sur les recommandations émises par les experts.
NOTE 1 L’un des principaux avantages d’un audit RCA est de faire correspondre les mesures rectificatives à
planifier aux critères de performances de service non satisfaits ou aux incidents de performance.
NOTE 2 Les risques économiques orientés performance sont inclus dans l’attribution des priorités.
Étape 5: Mettre en œuvre le plan d’action d’amélioration des performances des services
Si des composants de service sont affectés, une demande de changement est émise (à partir des
informations rassemblées lors des précédentes étapes et des recommandations relatives aux risques
de performance du service), et les éléments de configuration, nouveaux ou modifiés, sont insérés dans
le CPIR.
Si la demande de changement est acceptée, il convient de mener une nouvelle évaluation des risques
économiques orientés performance sur les services nouveaux ou modifiés, avant et après leur
déploiement dans l’environnement de production.
Si la demande de changement est refusée, les connaissances accumulées relatives à la performance du
service existant sont insérées dans le CPIR.
NOTE 1 L’ensemble du processus décrit adjoint au processus de gestion des déploiements (stratégie de tests
incluse), une démarche basée sur les risques économiques.
NOTE 2 Une évaluation est obligatoire pour vérifier l’efficience du correctif. Ses scores participent à la décision
de déploiement dans l’environnement de production.
NOTE 3 La résolution d’un problème de performance comprend le traitement et la correction de ses causes
(voir Figure 1).
NOTE 4 L’efficacité du correctif ne peut être validée que dans un environnement à l’image de la production.
Si le correctif n’est pas opérant, une nouvelle analyse du problème de performance est réalisée. Et si le correctif
est opérant, les informations rassemblées pendant la résolution du problème de performance sont insérées dans
le CPIR.
Le Tableau 2 résume le processus décrit.
8 © ISO/IEC 2017 – Tous droits réservés
Tableau 2 — Étapes du processus d’amélioration continue des performances (CPI)
Étape 1 Identifier les incidents de performance et les critères de performance non satisfaits
Étape 2 Identifier les problèmes de performance
Étape 3 Identifier les erreurs relatives aux problèmes de performance et spécifier les recommandations
permettant d’atténuer les risques économiques orientés performance associés
Étape 4 Qualifier le plan d’action
Étape 5 Mettre en œuvre le plan d’action d’amélioration des performances des services
NOTE Chaque étape ajoute des informations pouvant conduire à décider d’arrêter tout le processus. C’est
un processus d’amélioration itératif, utilisé pour tenir compte les contraintes de coût et de délai associées aux
besoins métiers.
4.2.2 Activités du processus
4.2.2.1 Préqualification des problèmes de performance
4.2.2.1.1 Préqualification des incidents de performance
Les éléments d’entrée proviennent de:
— la gestion de la relation commerciale;
— la gestion des niveaux de service.
Une fonction essentielle de la méthode LCRI est de déterminer, parmi les incidents (gérés par le
processus de gestion des incidents), les incidents de performance et les autres.
La qualification des incidents de performance est le point de départ d’un processus heuristique
d’identification du plan d’action traitant avec justesse les problèmes de performance associés.
4.2.2.1.2 Satisfaction des critères de performance du service
Les critères de performance du service sont extraits du CPIR, et ceux adaptés au service évalué sont
sélectionnés. Ce choix est fondé sur les erreurs connues associées aux composants de service concernés,
et sur le fonctionnement du service et de ses composants de service.
La vérification de la satisfaction des critères de performance du service s’effectue par des contrôles
techniques réguliers réalisés tout au long du cycle de vie.
L’objectif est d’interpréter les données issues des derniers contrôles techniques réalisés sur le service
évalué (si aucune évaluation n’a été menée, ce service est soumis à un contrôle technique).
4.2.2.2 Validation des performances des services nouveaux ou modifiés
Il convient que la validation s’effectue via un contrôle technique réalisé sur le ou les composants de
service participant aux services nouveaux ou modifiés.
NOTE Les contrôles techniques de validation peuvent être réalisés dans l’environnement de production ou
de tests. Pour ce dernier, la représentativité du service testé et une stratégie pilotée par les risques requièrent la
participation des experts du domaine. Cette stratégie peut être continuellement améliorée (par les experts, qui
n’ont pas à subir les contraintes de la production), pour que l’environnement de tests devienne une image de la
production.
Pour les incidents de performance, en plus des contrôles techniques, il convient que la validation soit
acceptée par l’utilisateur et/ou par une partie intéressée, conformément au processus de gestion de la
relation commerci
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...