Harmonized Stage Code system (Edition 2) — Principles and guidelines for use

Système des codes d'étape harmonisés (Édition 2) — Principes et directives d'utilisation

General Information

Status
Withdrawn
Publication Date
07-Jul-1999
Withdrawal Date
07-Jul-1999
Current Stage
9599 - Withdrawal of International Standard
Completion Date
18-Jun-2014
Ref Project

Relations

Buy Standard

Guide
ISO Guide 69:1999 - Harmonized Stage Code system (Edition 2) -- Principles and guidelines for use
English language
8 pages
sale 15% off
Preview
sale 15% off
Preview
Guide
ISO Guide 69:1999 - Systeme des codes d'étape harmonisés (Édition 2) -- Principes et directives d'utilisation
French language
9 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


GUIDE 69
Harmonized Stage Code system
(Edition 2) — Principles and
guidelines for use
First edition 1999

---------------------- Page: 1 ----------------------
ISO GUIDE 69:1999(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
Guides are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
Draft Guides adopted by the responsible Committee or Group are circulated to national bodies for voting.
Publication as a Guide requires approval by at least 75 % of the national bodies casting a vote.
ISO Guide 69 was prepared by the ISO Technical Management Board.
© ISO 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Organization for Standardization
Case postale 56 � CH-1211 Genève 20 � Switzerland
Internet iso@iso.ch
Printed in Switzerland
ii

---------------------- Page: 2 ----------------------
©
ISO ISO GUIDE 69:1999(E)
0 Introduction
0.1 The standardization process has a number of definite steps or stages which can be used both to describe the
process and to indicate where in the process any one item has reached. In general terms the methods used to
develop and publish standards via the formal standardization process operated by international, regional and
national standards bodies are very similar no matter which body is overseeing the process. Thus, at a high level, it is
possible to have a common view of the standardization process and with it a common set of stages. There are
differences between the processes of individual bodies, however, and this has led to the development of different
stage systems for each body.
0.2 The development of so many systems has led to some confusion amongst users and it was decided to develop
a Harmonized Stage Code system which could be used and understood by all bodies. The first version of this was
developed in 1993. This has now been revised and simplified.
iii

---------------------- Page: 3 ----------------------
©
ISO ISO GUIDE 69:1999(E)
Harmonized Stage Code system (Edition 2) — Principles
and guidelines for use
1 Scope
This Guide establishes a Harmonized Stage Code (HSC) system intended to be used in databases for tracking
standards development projects. It sets out the principles and guidelines for the use of the harmonized stage codes,
and is intended to facilitate exchange of information concerning standards projects between international, regional
and national standards bodies.
2 General principles of the system
2.1 The purpose of the HSC system is not to re-invent the stage system and make each body follow it exactly. Its
purpose is to provide a common framework for the transfer of core data, thus allowing each body to map its own
processes and system onto the core matrix. Each standards body can develop its own stage system for its own
use.
2.2 It is recognized that different customers have different requirements from a stage code system. Standards
organizations need a detailed system to enable workflow to be properly monitored, analysed and controlled. The
general public needs only an overview which is simple to understand. The HSC system enables these requirements
to be satisfied by providing a matrix overview of the whole process, whilst allowing the details to be included within
it.
2.3 A neutral procedural framework of codes has been established for application to the different procedures
currently in use by international, regional and national standards organizations.
2.4 This framework can be used for either mapping an existing stage code system onto the framework or for
developing a new stage code system around it.
2.5 The HSC matrix takes an unusual approach in that it mixes both stages/milestones with decisions, in that some
events have mutually exclusive sub-events, whilst some do not. This is necessary because of the nature of the
standards process, which mixes periods of activity (and therefore completed activities) with decisions which could or
must be made either during or after those periods of activity. Whilst this approach reduces the need to hold
information about these decisions in separate database fields, it is recommended that certain information (e.g.
project status) is held in other fields.
2.6 Only the given codes within the framework are valid for data transfer. Other codes may be included for internal
purposes only (see clause 5), but they shall not be transferred to other bodies as part of a database extract. This is
governed by the rules indicated within the ISONET Manual.
2.7 Only certain stages are possible. Those that are not possible are indicated.
2.8 The system allows tracking of the development of a given project in the same way in databases being used at
international, regional and national levels. The adoption of a project from one level to another (e.g. international to
national, or regional to national) is therefore able to be incorporated in the overall sequence of codified events.
2.9 The framework proposed can accommodate new procedures that may be developed in the future. The overall
standards-making process is similar in each organization, thus any changes to existing processes are likely to be
1

---------------------- Page: 4 ----------------------
©
ISO GUIDE 69:1999(E) ISO
common ones. Even allowing for a complete rethink in the standards process, the matrix is so constructed that it can
easily be adapted to new requirements.
2.10 Only the Harmonized Stage Code group is allowed to authorize the use of any new phase or sub-phase
number or any new main event number. Individual organizations have the flexibility to use sub-event numbers.
3 Design of the stage code matrix
3.1 A series of "phases" representing procedural sequences common to different organizations has been
established. These represent the main stages of standards development.
3.2 A series of "events" has been established within each phase, using a consistent logical system of concepts.
The terms "phase" and "event" are hence used to designate the respective axes of the resulting matrix.
3.3 Principal phases and events are each coded by a two-digit number from 00 to 90, in increments of 10 to allow
for interpolation (using the second digit) of "sub-phases" and "sub-events" that might occur in the procedures of one
body or another. Such interpolation has already been made in a number of cases in the proposed matrix. The only
events available for "free" use are the events not ending in the digit "0" that have not already been designated. It is
recognized that there is a need for a rapid change mechanism when new common codes are needed.
3.4 Individual cells within the generic matrix are coded by a four-digit number made up of its phase and event
coordinates. For visual presentation (although not necessarily for the purposes of database operations), the pair of
coordinates are separated by a point (e.g. 10.20 for phase 10, event 20).
3.5 All unused phase codes are reserved for future use, to allow for interpolation of additional phases that might be
identified.
3.6 The event codes 10, 30, 40, 50 and 80 are reserved for future use, to allow for interpolation of additional event
types that might be identified. Of these, the event codes 30, 40 and 50 occur within the main action events of xx.20
to xx.60. A number of internal actions/stages may be required between xx.20 and xx.60. Therefore, users may
designate events 30, 40, 50 as internal stages providing it is recognized that they would have to amend their
internal systems if these codes are required in the future for the main matrix. Such a requirement may occur if the
actions that occur become more uniform between standards organizations.
3.7 Within each standards development process, there are a number of special stages which can be called
"milestones". These mark a key point within the process. Within the HSC matrix system there are a number of
common milestones which should be recognizable by all standards bodies. Others may exist within the processes
of individual bodies. These common milestones are stages 00.00, 10.00, 20.00, 40.20, 40.60, 50.20, 50.60, 55.60,
60.60, 65.60, 90.20. These are marked by "M" in the matrix. From the review phase onward, other common
milestones are stages 90.60, 91.60, 92.60, 99.60. These are marked by "m" in the matrix. Although these
milestones are important stages, like all other stages they are optional and need not be recorded if they are not
suited to an organization’s way of working.
4 Basic guidelines for using the system
4.1 The common codes proposed have generic meanings so that comparable procedures are identifiable explicitly
by identical stage codes by each organization within its own context. Thus each organization may rename a code in
accordance with its own terminology, providing that the generic meaning and local meaning are synonyms.
4.2 Different phases and events are important to different bodies, and each is free to adopt only those that are
applicable to its own purposes.
4.3 Each stage code represents an action. That action maybe the beginning or end of an activity or a decision
based on some aspect of that activity. Certain stages may be considered as milestones in the lifetime of a project.
4.4 Other information concerning, for example, document source or document type, should be recorded in
separate database fields and should not be reflected in stage codes.
2

---------------------- Page: 5 ----------------------
©
ISO ISO GUIDE 69:1999(E)
4.5 There is no sub-code to indicate that a project is dormant at any particular stage. It is recommended to use
another database field to address this issue.
4.6 The HSC system allows for the cyclical nature of the standards process and for the repeating of either the
current phase or an earlier phase. Events that may be repeated in the life of a project are recordable by repetition of
the same stage codes. For example, if it is just a procedure that is being repeated (for example, because of a
procedural error) and a decision event is required, then event xx.93 should be used. Alternatively, for example, if a
document is incorrect and needs to be redrafted and a decision event is required, then event xx.92 should be used.
It is recommended that tracking of versions or iterations in either the same or different phases or events should be
handled by separate numeric fields in the database.
4.7 The backstaging and freezing of projects are issues for the local operation of the HSC. Projects may be
backstaged to any other point in the system by using (usually) event xx.92 or xx.93. Freezing a project at any point
is possible by either just using the code the project has reached or, alternatively, using event xx.91. Other codes
may be used locally, but care shall be taken over which code is transferred. Projects that have been suspended
should also have this information recorded in a separate database field.
4.8 The HSC system is not concerned with recording either target or actual dates for achieving stages. Under
ISONET guidelines, other data fields should be used to record target and/or actual dates associated with specific
stages. The individual standards body should decide for which stages it wishes to hold this information and should
also maintain this information within its own database system.
4.9 The phase labelled "00: Definition of new project" should not be used to put back projects into abeyance once
work at a subsequent stage has already been started, unless it is intended to reprocess the project totally.
4.10 A distinction is made between the event-types action (codes 20 to 60/70) and decision (code 90) because
these could in practice be significantly separated in time.
4.11 The stage xx.60 is the end of a main action and no other stage should represent a completion of a main action.
However, there are a few phases where a small subsequent action is required, such as the dispatching of results.
This is catered for by using event xx.70. Once a project has reached event xx.60/xx.70, the next event can be either
one of events 91 to 99 or the next appropriate phase. Only one of the xx.90 events is possible at any one time.
4.12 The phase labelled "60: Publication stage" is intended to designate the publishing of the standard by the
developing body. Phase "65: Implementation stage" is intended to accommodate the implementation by one body of
a standard that has been developed within another body. Usually, but not always, this will be the national
implementation of a regional or international standard.
4.13 The use of event xx.90 is different from the others in that there is a choice of Decisions which can be made,
hence the different layout for this event. If event xx.92 or xx.94 is used,
...


GUIDE 69
Système des codes d'étape
harmonisés (Édition 2) —
Principes et directives
d'utilisation
Première édition 1999

---------------------- Page: 1 ----------------------
GUIDE ISO 69:1999(F)
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 ou non gouvernementales, en
liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Guides sont rédigés conformément aux règles données dans les Directives ISO/CEI, Partie 3.
Les projets de Guides adoptés par le comité ou le groupe responsable sont soumis au vote des organismes
nationaux. La publication en tant que Guide requiert l'approbation de 75 % au moins des organismes nationaux
votants.
Le Guide ISO 69 a été élaboré par le Bureau de gestion technique.
© ISO 1999
Droits de reproduction réservés. Sauf prescription différente, 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 et les microfilms, sans l'accord écrit de l'éditeur.
Organisation internationale de normalisation
Case postale 56 � CH-1211 Genève 20 � Suisse
Internet iso@iso.ch
ImpriméenSuisse
ii

---------------------- Page: 2 ----------------------
©
ISO GUIDE ISO 69:1999(F)
0 Introduction
0.1 Le processus de normalisation se compose d’un nombre précis d’étapes ou de stades qui permettent à la
fois de le décrire et d’indiquer tout point atteint au cours de son déroulement. D’un point de vue général, les
méthodes d’élaboration et de publication de normes mises en œuvre dans le processus de normalisation formel
suivi par les organismes internationaux, régionaux et nationaux de normalisation sont très proches, quel que soit
l’organisme chargé de superviser le processus. Cela permet donc d’avoir, à un niveau élevé, une vision commune
du processus de normalisation, avec un même ensemble d'étapes. Il existe néanmoins des différences entre les
démarches suivies par les divers organismes, ce qui a entraîné l’élaboration de systèmes d’étapes distincts pour
chacun d’eux.
0.2 L’apparition d'un très grand nombre de systèmes a quelque peu déconcerté les utilisateurs, et c'est ainsi
qu'il a été décidé de mettre au point un système de codification d'étapes harmonisé (HSC), à même d’être employé
et compris par tous les organismes. Après une première version établie en 1993, ce système a été revu et simplifié.
iii

---------------------- Page: 3 ----------------------
©
ISO GUIDE ISO 69:1999(F)
Système des codes d'étape harmonisés (Édition 2) —
Principes et directives d’utilisation
1 Domaine d'application
Le présent Guide établit un système de codes d'étape harmonisé (HSC) prévu pour être mis en œuvre dans les
bases de données pour la traçabilité des projets de développement de normes. Il énonce les principes et directives
d'utilisation des codes d'étape harmonisés, et est prévu pour faciliter l'échange d'information concernant les projets
de normes entre organismes de normalisation internationaux, régionaux et nationaux.
2 Principes généraux du système
2.1 Le système HSC ne vise pas à réinventer un système d'étapes et à obliger chaque organisme à le suivre
scrupuleusement. Il entend au contraire fournir un cadre commun pour la reprise des données essentielles,
permettant ainsi à chaque organisme de concevoir ses propres procédures et système autour d’une matrice de
base. Tous les organismes de normalisation peuvent élaborer leur système d'étapes particulier en fonction de leurs
propres besoins.
2.2 Il est établi que des utilisateurs différents n’ont pas les mêmes attentes à l’égard d’un système de
codification d'étapes. Les organisations de normalisation ont besoin d’un système détaillé qui permette de contrôler,
d’analyser et de maîtriser correctement le flux de production. Le public ne demande, quant à lui, qu’une vue
d’ensemble intelligible. Le système HSC permet de satisfaire à ces deux exigences en proposant une matrice qui
donne une vision globale de tout le processus, sans exclure pour autant les détails.
2.3 Il a été établi un cadre de codes procédural et neutre, destiné à s’appliquer aux différentes procédures
actuellement utilisées par les organisations internationales, régionales et nationales de normalisation.
2.4 Ce cadre peut servir à modifier un système de codification d'étapes existant en vue de l’y conformer ou à
élaborer un nouveau système de codification d'étapes fondé dessus.
2.5 La matrice HSC a une approche inhabituelle, en ce sens qu’elle mêle des étapes/des jalons à des
décisions, certains événements ayant des sous-événements qui s’excluent mutuellement, d’autres, non. Cet état de
fait résulte de la nature même du processus de normalisation: ce dernier repose à la fois sur des périodes d’activité
(et donc des activités terminées) et des décisions qui pourraient ou doivent être prises pendant ou après ces
phases d’activité. Si grâce à cette approche, il n’y a plus autant besoin de stocker les informations concernant ces
décisions dans des champs de base de données distincts, il est toutefois recommandé d’enregistrer certaines
informations, comme l’état du projet, dans d’autres champs.
2.6 Seuls les codes donnés au sein du cadre sont valables pour la reprise de données. Il est possible d’inclure
d’autres codes à des fins internes, uniquement (voir l'article 5), mais ils ne doivent pas être repris par d’autres
organismes qui emploieraient partiellement une base de données. Ceci est régi par les règles qui figurent dans le
manuel ISONET.
2.7 Seules certaines étapes sont possibles. Celles qui ne sont pas possibles sont indiquées.
2.8 Le système permet un suivi de l’évolution d’un projet donné de la même manière dans toutes les bases de
données, qu’elles soient utilisées à un niveau international, régional ou national. L’adoption d’un projet d’un niveau à
1

---------------------- Page: 4 ----------------------
©
GUIDE ISO 69:1999(F) ISO
un autre (international à national, ou régional à national, par exemple) devient ainsi intégrable dans la séquence
globale des événements codifiés.
2.9 Le cadre proposé pourra incorporer les nouveaux processus qui seraient élaborés ultérieurement. Le
processus global d’élaboration de normes est semblable dans chaque organisation; toute modification apportée à
des processus existants est donc censée être commune. Même si le processus de normalisation devait être
complètement repensé, la matrice est conçue de façon à pouvoir être facilement adaptée aux nouvelles exigences.
2.10 Seul le groupe chargé de la codification d'étapes harmonisée peut autoriser l’emploi d’un nouveau numéro
pour une phase, une sous-phase ou un événement principal. Des organisations particulières disposent de plus de
souplesse: elles peuvent utiliser des numéros pour les sous-événements.
3 Conception de la matrice de codification d'étapes
3.1 Une série de «phases» représentant des séquences procédurales communes à différentes organisations a
été établie. Celles-ci correspondent aux principaux stades de l’élaboration de normes.
3.2 Au sein de chaque phase a été établie une série d’«événements», selon un système cohérent et logique de
concepts. Les termes «phase» et «événement» désignent donc les axes respectifs de la matrice finale.
3.3 À chaque phase et événement principal correspond un code, numéro à deux chiffres compris entre 00 et 90
et incrémenté de 10 à chaque fois, afin de permettre l’interpolation (avec le deuxième chiffre) de «sous-phases» et
de «sous-événements» susceptibles d’exister dans les procédures de l’un quelconque des organismes. Une telle
interpolation a déjà été effectuée à plusieurs reprises dans la matrice proposée. Les seuls événements d’emploi
«libre» sont ceux qui ne se terminent pas par le chiffre «0» et qui n’ont pas encore été attribués. Il a été reconnu
qu’un mécanisme de changement rapide était nécessaire pour répondre au besoin éventuel de nouveaux codes
communs.
3.4 À chaque cellule de la matrice correspond un code de quatre chiffres composé de ses coordonnées
«phase» et «événement». À des fins de représentation visuelle (et donc pas nécessairement pour les besoins des
opérations au niveau de la base de données), un point sépare les deux coordonnées; 10.20 correspond ainsi à la
phase 10, événement 20.
3.5 Tous les codes d'étapes inutilisés sont conservés en vue d’un emploi ultérieur, afin de permettre
l’interpolation d'étapes supplémentaires qui viendraient à être identifiées.
3.6 Les codes d’événements 10, 30, 40, 50 et 80 sont conservés en vue d’un emploi ultérieur, afin de permettre
l’interpolation d’autres événements qui viendraient à être identifiés. Parmi ceux-ci, les numéros 30, 40 et 50 se
situent dans les événements de l’action principale, de xx.20 à xx.60. Plusieurs actions et/ou étapes internes peuvent
s’avérer nécessaires entre xx.20 et xx.60. Les utilisateurs ont donc la possibilité de désigner les événements 30, 40
et 50 comme codes internes, à partir du moment où il est reconnu qu’ils auront à modifier leurs systèmes internes si
ces indicatifs doivent servir à la matrice principale. Une telle exigence peut naître d’une uniformisation plus poussée
des actions entreprises par les organisations de normalisation.
3.7 Au sein de chaque processus d’élaboration de normes, divers codes spéciaux peuvent être appelés
«jalons», car ils correspondent à un moment clé du processus. Le système de matrice HSC renferme plusieurs
jalons communs; il convient qu’ils soient identifiables par tous les organismes de normalisation. Il est possible qu’il
en existe d’autres au sein des procédures d’organismes particuliers. Ces jalons communs correspondent aux
stades 00.00, 10.00, 20.00, 40.20, 40.60, 50.20, 50.60, 55.60, 60.60, 65.60, 90.20. Ils sont matérialisés par «M»
dans la matrice. Les autres jalons communs qui, chronologiquement, viennent après la phase d’examen, sont les
étapes 90.60, 91.60, 92.60, 99.60. Ils sont matérialisés par «m» dans la matrice. Bien qu’ils correspondent à des
étapes importantes, ces jalons sont facultatifs, comme toute autre étape, et n’ont pas à être enregistrés s’ils ne
correspondent pas au mode de fonctionnement de l’organisation concernée.
2

---------------------- Page: 5 ----------------------
©
ISO GUIDE ISO 69:1999(F)
4 Directives fondamentales concernant l’utilisation du système
4.1 Les codes communs proposés ont une signification générique qui permet à chaque organisation, dans son
propre contexte, d’identifier clairement des procédures comparables grâce à une codification d'étapes identique.
Chaque organisation peut donc renommer un code selon sa propre terminologie, à partir du moment où les
significations générique et locale sont synonymes.
4.2 Les divers organismes n’accordent pas la même importance aux différents événements et phases, et
chacun est libre d’adopter uniquement ceux qui s’appliquent dans la réalisation de ses propres objectifs.
4.3 Chaque code d'étape représente une action. Cette dernière peut être le début ou la fin d’une activité, ou
une décision fondée sur l’un des aspects quelconques de cette activité. Il est possible de considérer certaines
étapes comme des jalons dans la vie d’un projet.
4.4 Il convient de stocker d’autres données relatives à l'origine ou au type du document, par exemple, dans des
champs de bases de données distincts et de ne pas les traduire par des codes d'étape.
4.5 À aucune étape, il n’existe de code intermédiaire représentant un projet «en sommeil». Il est recommandé
d’utiliser un autre champ de base de données pour traiter cet état de fait.
4.6 Le système HSC prend en compte le caractère cyclique du processus de normalisation et la répétition de la
phase courante ou d’une phase antérieure. Il est possible d’enregistrer des événements susceptibles de se
reproduire au cours de la vie d’un projet en répétant les mêmes codes d'étape. S’il s’agit juste d’une procédure qui
se réitère (en raison d’une erreur procédurale, par exemple) et qu’un événement de décision s’avère nécessaire,
par exemple, il convient d’employer l’événement xx.93. Autre cas de figure possible: lorsqu’il faut reprendre la
rédaction d’un document pour cause d’inexactitude et que l’enregistrement d’un événement s’impose, il convient
d’utiliser l’événement xx.92. Il est recommandé de traiter par des champs numériques séparés de la base de
données le suivi des versions ou des itérations dans les phases ou événements identiques ou différents.
4.7 Le renvoi à une étape antérieure et le gel des projets relèvent du fonctionnement local du HSC. Les
événements xx.92 ou xx.93 permettent (habituellement) de rétrograder des projets à n’importe quel autre point
antérieur du système. Il est possible de geler un projet à tout moment en utilisant simplement le code de son point
d’avancement ou en recourant à l’événement xx.91. D’autres codes peuvent être employés localement, mais il faut
faire attention au code repris. Dans le cas de projets suspendus, il convient d’enregistrer également cette
information dans un champ distinct de la base de données.
4.8 Le système HSC ne vise pas l’enregistrement de dates cibles de réalisation pour l’accomplissement des
étapes. Conformément aux directives ISONET, il convient d’employer d’autres champs pour enregistrer des dates
cibles et/ou de réalisation, associées à des étapes spécifiques. Il est recommandé que chaque organisme de
normalisation décide des étapes pour lesquelles il souhaite avoir ces informations et les garder au sein de son
propre système de bases de données.
4.9 Une fois le travail débuté à une étape ultérieure, il convient de ne pas utiliser la phase intitulée
«00: Définition du nouveau projet» pour remettre des projets en attente, à moins que l’objectif soit de réinitialiser
totalement le projet.
4.10 Une distinction s’opère entre les types d’événements «action» (indicatifs 20 à 60/70) et «décision»
(indicatif 90), car il peut arriver que ces derniers soient très dissociés dans le temps.
4.11 L'étape «xx.60» constitue la fin d’une action principale, et il convient qu’aucune autre étape ne corresponde
à l’aboutissement d’une action principale. Dans certaines phases toutefois, une petite action ultérieure s’impose,
comme la diffusion des résultats. L’événement prévu à cet effet est le xx.70. Une fois qu’un projet a atteint
l’événement xx.60/xx.70, l’événement suivant peut être l’un des événements 91 à 99 ou la prochaine phase idoine.
À un moment donné, un seul et unique événement parmi les xx.90 est possible.
3

---------------------- Page: 6 ----------------------
©
GUIDE ISO 69:1999(F) ISO
4.12 Dans la phase intitulée «60: Stade publication», l’objectif est la désignation de la publication de la norme
par l’organisme qui l’a élaborée. Dans la phase «65: Étape mise en application», le but est qu’un organisme adapte
la mise en application d’une norme élaborée au sein d’un autre organisme. Il s’agit généralement, mais pas
toujours, de la mise en application d’une norme régionale ou internationale au niveau national.
4.13 L’emploi de l’événement xx.90 diffère des autres car il est possible d’y prendre diverses décisions: il se
présente donc autrement.
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.