ISO/TS 16175-2:2020

TECHNICAL ISO/TS
SPECIFICATION 16175-2
Second edition
2020-10
Information and documentation —
Processes and functional
requirements for software for
managing records —
Part 2:
Guidance for selecting, designing,
implementing and maintaining
software for managing records
Information et documentation — Processus et exigences
fonctionnelles applicables aux logiciels de gestion des documents
d'activité —
Partie 2: Recommandations pour le choix, la conception, la mise
en oeuvre et la tenue à jour des logiciels de gestion des documents
d’activité d'activité
Reference number
©
ISO 2020
© ISO 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Assessing the organizational framework and context . 1
4.1 General . 1
4.2 Organizational records maturity . 2
4.3 Records controls . 3
4.4 Technical environment. 3
4.4.1 General. 3
4.4.2 Paper environment . 3
4.4.3 Digital environment . 3
4.4.4 Hybrid environment . 5
4.5 Project scoping and resources . 5
5 Determining a project methodology . 7
5.1 General . 7
5.2 Defining stakeholders . 7
6 Determining and managing functional requirements . 8
6.1 Developing functional requirements . 8
6.2 Considerations for defining functional requirements . 8
6.3 Managing functional requirements . 9
7 Determining configuration . 9
7.1 General . 9
7.2 Importance of documentation of configuration decisions .10
7.3 Configuration decisions — Areas of configuration .10
7.3.1 General.10
7.3.2 Records aggregation .11
7.3.3 Agents (Users).12
7.3.4 Business process .12
7.3.5 Metadata schema for records .12
7.3.6 Business classification schemes .13
7.3.7 Access and permission rules .13
7.3.8 Disposition authorities .13
7.3.9 User interface . .13
7.3.10 Supported automation .13
7.3.11 Supported automation tools .14
7.3.12 Automated capture of records process metadata .14
7.3.13 Integration needed to other existing business software .14
7.3.14 Applicable records-specific rules .14
8 Determining requirements to migrate and convert records .15
9 Communication, training and change management .15
9.1 General .15
9.2 Communications .16
9.3 Training program requirements .16
9.4 Change management readiness .16
9.5 E valuation and review .17
10 Post-implementation review, monitoring and assessment .18
10.1 Post-implementation review .18
10.2 Monitoring .18
10.3 Assessment .19
Annex A (informative) Considerations for a methodology for implementing software for
managing records .20
Bibliography .22
iv © ISO 2020 – All rights reserved

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.
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 of 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 www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 46, Information and documentation,
Subcommittee SC 11, Archives/records management.
This second edition of ISO/TS 16175-2 cancels and replaces ISO 16175-2:2011 and ISO 16175-3:2010,
which have been technically revised. The main changes compared to the previous editions are as
follows:
— functional requirements for software that were previously provided in ISO 16175-2:2011 and
ISO 16175-3:2010 have been updated and consolidated;
— guidance on implementing software for digital records that was previously provided in all three
parts of the previous edition of the ISO 16175 series has been updated and consolidated;
— in an updated form, some generic content on implementing records systems (both digital and
analogue), that was previously provided in the now withdrawn ISO/TR 15489-2:2001 have been
included.
A list of all parts in the ISO 16175 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user's national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
Introduction
All organizations have at least one records system. Records systems are information systems which
capture, manage and provide access to records over time. Records systems can consist of technical
elements such as software, and non-technical elements such as policy, procedures and agents. Records
systems as a whole include the policy, processes, software and people that use and manage records.
Records systems exist in many variations: in paper systems, in software specifically designed to meet
functionality for managing records, or as business software which capture and manage records. This
document is focused on management of records in the digital environment, using software, but the
general principles and considerations apply whatever the environment.
This document makes no distinction between software applications that are used for any business
purpose and those applications specifically intended and designed to manage records. Examples of
the former include Enterprise Content Management Systems and applications which create records
as one part of their functionality such as Contracts Management Systems, Case Management Systems
or transactional systems. The term used throughout is therefore “software for managing records”,
which is intended to encapsulate the totality of applications that manage records as part of their usual
functioning. It is assumed that almost all business applications generates data that is needed to serve as
evidence of business activity for future reference and as such, among other things, need to create, store
and manage records, whether within their own functionality or in combination with other applications.
Clauses 4 and 5 provide guidance on assessing the context of the organization and on scoping a project to
implement software for managing records. Clauses 6 to 8 provide guidance on identifying requirements
for the functionality of the software, including those for conversion and migration. Clause 9 provides
guidance on communication, training and change management. Clause 10 provides guidelines for post-
implementation review.
ISO 16175-1 provides a set of model functional requirements and associated guidance for software for
managing digital records.
vi © ISO 2020 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 16175-2:2020(E)
Information and documentation — Processes and
functional requirements for software for managing
records —
Part 2:
Guidance for selecting, designing, implementing and
maintaining software for managing records
1 Scope
This document provides guidance for decision making and processes associated with the selection,
design, implementation and maintenance of software for managing records, according to the principles
specified in ISO 15489-1.
This document is applicable to any kind of records system supported by software, including paper
records managed by software, but is particularly focused on software for managing digital records.
This document provides guidance to records professionals charged with, or supporting the selection,
design, implementation and maintenance of systems for managing records using a variety of software.
It can also provide assistance to information technology professionals such as solution architects/
designers, IT procurement decision makers, business analysts, business owners and software
developers and testers seeking to understand records requirements.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 30300, Information and documentation — Records management — Core concepts and vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 30300 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
4 Assessing the organizational framework and context
4.1 General
Organizations have distinct cultures which usually affect their approach to managing records. These
cultures are part of the organizational context. Factors that impact the information culture of an
organization include:
— the values, attitudes and behaviours of organizational users;
— the technical environment; and
— the societal and organizational requirements, including legislation and/or regulation, standards
and related policy containing requirements for managing records and outline compliance.
The organizational culture affects decisions on selection and implementation of systems and software
for managing records. Where an organization has a defined information governance framework, the
system for managing records should be integrated with the information governance framework.
Where software for managing records supports processes shared by multiple organizations,
information culture factors should be considered for each organization. Selection and design of
software for managing records should be responsive to the needs of each organization. Responsibility
and ownership for managing cross-organizational systems and the rights in managing records created
in such shared software environment should be clearly assigned.
Selection and design of software for managing records should be undertaken within an organizational
framework that defines the policies and responsibilities to be implemented, and the records control
elements needed to scope the project. The following aspects should be considered during the planning
stages of any implementation:
— organizational records maturity;
— records controls;
— technical environment; and
— project scoping and resources.
4.2 Organizational records maturity
Assessing organizational records maturity helps guide the selection, design and implementation
of software for managing records. Undertaking an assessment of organizational maturity enables
benchmarking of progress over time, and assessment amongst similar organizations.
The following elements contribute to assessing organizational records maturity:
— whether strategic responsibilities for managing records are included in the senior management
responsibilities;
— whether records and their management are considered explicit components of information
governance;
— whether records functionality is included as a core component of the enterprise information
architecture supporting technology development and deployment;
— the level at which responsibility is assigned to resource, enforce and monitor conformance with
records principles;
— the availability of trained users and operational users in designing, implementing and maintaining
software for managing records;
— the organizational culture and the extent of awareness of responsibilities for creating and managing
records within the organization;
— what policies, standards and guidance outlining records responsibilities and obligations have been
developed for the organization, whether they are current and whether they are compliant to the
relevant jurisdiction;
— whether records requirements have been incorporated into information governance frameworks
and all relevant organizational policies, standards and guidelines (for example privacy, information
security, or disaster recovery);
2 © ISO 2020 – All rights reserved

— whether records have been linked to organizational and/or functional risk assessments;
— whether the key records controls are up to date and are available for use;
— what existing records systems are in place;
— links between existing records systems; and
— what support is available to users in understanding their records responsibilities.
4.3 Records controls
Records systems can be designed in many ways to support business, and more than one records
system may exist within the organization as a whole. Records controls should be devised at an
organizational level whenever possible, so that they can be applied consistently to all records without
constraining the organization to using a single software application. These records controls identified
in ISO 15489-1:2016, Clause 8, should be developed prior to the implementation of a specific software
for managing records.
Records controls developed at organizational level can be used to develop more specific records controls
that can be supported by software to manage records which operate at a smaller level – for example,
controls applying to a part of the organization, or relating to a specific function. The organizational
records controls can form the design template from which the specific elements particularly suited to
the scope of the software implementation can be extracted, or developed in further detail if needed.
4.4 Technical environment
4.4.1 General
The following subclauses address common technical environments in which software for managing
records are deployed.
4.4.2 Paper environment
Paper records systems are often organized into files which physically group documents representing
organizational transactions together in ways that reflect their formation. Paper files are typically
managed and accessed through registers and indexes that are often automated using software.
4.4.3 Digital environment
4.4.3.1 General
Many organizations now operate in a digital environment. While some paper records can still be
created or received, these are converted to digital form using digitization processes and the digitized
records are incorporated into the records system for processing. For guidance on digitization, see
ISO/TR 13028.
In this environment, the main concern is to deploy software that supports the characteristics of
authoritative records (that is, authenticity, reliability, integrity and useability). It is also usually
important to enable the digital records (including their metadata) to persist beyond the lifetime of the
software application in which they were initially managed. At the same time, the resources to support
the management of digital records should be defined.
It is important that digital continuity be maintained. Software usually has a practical lifespan of about
5 to 10 years prior to major upgrade or replacement. Issues to be considered in addressing digital
continuity include:
— data which need to be considered as a record may no longer be stored and accessible in recognized
documentary form. Data fields in databases which provide evidence of transactions are records.
Such systems are often business applications which need to consider how to maintain the evidence
of business. On some occasions, structured metadata defined for particular industries can inform
the configuration of metadata elements. Key to considering implementation of records requirements
in these environments is determining:
— what constitutes the evidence of the business;
— how to ensure that it is reproducible as presented to a user at a particular time;
— details of what changed; and
— when and who changed the data field contents.
This should be done using the process of appraisal. For further guidance on appraisal, see
ISO/TR 21946.
— some business applications enable storage of documents within their software boundaries.
Documents can be constantly changing, whereas records should be protected from unauthorised
changes to ensure their evidential integrity.
— documents can be composed of data, which can be stored separately and represented as a single
view (document) when required. The capacity to store data and disaggregated content separately,
and both separate to the media, requires implementing records controls.
— workflow tools may be used to support authorizations and approvals. Such tools often utilize links
and email notifications, and act as connectors between specific software. The workflow definitions
themselves can be required as records, as can the results of those workflows – particularly approvals
or authorizations.
All projects which seek to implement fundamental change from paper to digital should comprehensively
understand the legislation, regulation and any rulings on:
— mechanisms for asserting authenticity, such as electronic signatures;
— requirements to define adequate processes to ensure the legal admissibility of digital copies of
analogue records; and
— jurisdictional requirements to retain certain physical records after digitization.
4.4.3.2 Cloud computing environment
Cloud services are increasingly being used to provide storage and flexible access to software and
digital records. Multiple options exist for procurement and deployment of cloud services. Options
include software as a service, software with a browser-based user interface and storage of records in
the cloud. For records, this “as a service” approach usually involves storage of digital records on servers
external to the organization. As products emerge which are designed for the cloud environment,
records software functionality is increasingly being made available as a service. At present this is
typically access to a single proprietary set of functionality or software providing records functionality.
Over time, it is anticipated that smaller and smaller bundles of functionality will be made available as
services, allowing clever implementations to build the required records processes and functionality
from multiple different service applications.
In this environment, in addition to the issues of authenticity and sustainability, organizations need
to consider jurisdictional rules around data sovereignty, network security and developing adequate
contractual and technical frameworks to guarantee an adequate level of service. Requirements relating
to the end of the service and migration from one platform to another need to be addressed when
initiaiting service agreements. Risk assessment tools supporting decisions on adopting cloud-based
services are available in a number of jurisdictions.
4 © ISO 2020 – All rights reserved

4.4.3.3 Web-based collaborative software
Software for managing records can be available as web-based software which organizations deploy
flexibly on demand as the organization size and requirements change. Such software can involve
multiple agents, including those external to the organization – for example, suppliers or providers
of services. Both parties use the same software to document transactions and communications.
Considerations for records in this technology environment include the following.
— Who is responsible for managing authoritative records?
— Who owns the record?
— Who is the designated custodian of the system, to manage controls such as security permissions,
access rights, etc.?
— Can the system support extraction of records that have to be incorporated into different
organizational systems?
— What happens to the data at the end of contracts? Contracts may be for the software licence, for
storage, for services or for the business activity.
As with cloud-based systems, issues around jurisdictional rules relating to data sovereignty, network
security and adequate contractual and technical frameworks to guarantee adequate levels of service,
should be considered.
4.4.4 Hybrid environment
Records are increasingly being "born digital". The option to print these documents to paper and return
to the paper environment is sometimes advocated, as an interim stage on the way to more fully digital
management environments. Where records are received in paper form but the organization's responses
are created in digital form, the environment is known as "hybrid" – simultaneously containing both
paper and digital records.
Different approaches to this complex environment exist. There are compromises in each approach
which should be assessed against specific organizational needs. Approaches include the following.
— Maintaining separate systems for digital records and paper records (e.g. managing emails and their
attachments in the mail system and managing paper files in another system). If possible uniform
records controls such as business classification schemes should be standardized across the two
technical environments to minimize the pain of a user having to access two or more discrete
systems.
— Creating a "master" structure in the software which establishes unique logical containers referencing
both digital and paper records with the location and format of the record referenced as a separate
media type.
4.5 Project scoping and resources
Consideration of the issues discussed in 4.1 to 4.4 enable the project to be scoped. Software for
managing records may be implemented to serve different requirements, varying from supporting
records in specific business software, to software for managing records to support part or all of the
organization. The boundaries of the project should be identified.
Initially, the project should define its boundaries in relation to the business.
— Will the software support the whole organization or parts of the organization? Specify which
business functions, activities or organizational sections to be included in the project.
— Are the existing business processes to be automated, or is there opportunity to re-define business
processes impacting records creation and maintenance?
— How is the software going to be used? For example will it be a standalone software, or will records
be incorporated into an existing, or planned new, business system, or will an interface between
specific software for managing records and business systems be used?
— Who will use and interact with the system? What constraints or opportunities does this present?
Once the boundaries have been established, knowledge of the business functions and activities
undertaken by those areas within scope is essential. This involves:
— commencing an appraisal process with a scope defined by the project boundaries;
See ISO/TR 21946 for guidance on records appraisal processes. If applicable, results of previous
appraisal processes conducted within the organization may be reused.
— identifying existing business or software for managing records currently in use which may require
integration, decommissioning or other design options to any new software being designed (see
further Clause 6).
In defining the scope of a project, an initial assessment of resources and capacity which may affect the
project should be undertaken. Where software for managing records are being assessed, these may
include:
— Business context: Some organizations may be required to conform to strategic directions established
by other parties, for example, government departments can be required to follow jurisdiction-wide
rules. These strategic directions may impact options available for implementation. For example,
a jurisdiction may require use of open source software or use of a private government cloud, or a
management direction may already have established a "cloud-first" policy, or that existing platform
software will be used, or a specific software may be dictated by other organizational purchases.
Such management decisions frame what technology directions an organization can take, and in
turn, may define the parameters in which implementation of software for managing records can
take place.
— IT Infrastructure and networks: Software for managing records, especially those that
incorporate digitized images, can be very resource intensive if the organization does not have the
necessary infrastructure on networks to cope with the additional volume and size of information.
Considerations include: network speed, bandwidth, storage capacity, resolution available on user
screens, etc.
— Software scalability: Scalability is the capability of software, network, or process to handle a
growing amount of work, or its potential to be enlarged in order to accommodate that growth. The
extent to which software for managing records may need to "scale up" to larger, or organization-
wide deployment needs to be considered and planned for at an early stage in the implementation of
software, to meet organization's business needs. Business environments often change significantly
during the development or life of specific records or business software. Software for managing
records should be flexible to adjust the change of business needs and records requirements.
— Software performance: Software for managing records, like all technology systems, need to define
appropriate software performance parameters. The most important indicators for performance are
response time and data processing throughput speeds. It is expected that software will behave
in a predictable manner when these variables change. Establishing appropriate software system
performance criteria will define the necessary technology resources for performance-critical
business processes to run smoothly. Performance criteria should be developed by taking into
account the functional requirements and metadata requirements of records processes and records
controls to meet organizational records requirements. (Further considerations are documented in
ISO/TR 14105).
— Budget: All costs associated with implementing the software should be identified. This includes
costs for selection and initial configuration, in addition to change management and training
associated with initial implementation. Ongoing costs should be identified and assigned beyond a
specific project budget allocation. These costs include ongoing training and support.
6 © ISO 2020 – All rights reserved

— Skill capability: Implementing software for managing records involves:
— organizational capability and skills in relation to business analysis;
— understanding the organizational context and records maturity;
— identifying and assessing the available technology products;
— technical skills to implement and administer the software;
— specialist records skills to design and implement records controls within the software; and
— significant change management resources.
5 Determining a project methodology
5.1 General
Implementing a project to introduce software for managing records can be undertaken at different
levels of complexity. An implementation methodology should be determined to suit the project scope
and the scope of the software being implemented.
A project management methodology is commonly used to manage the project itself. The methodology
chosen should be appropriate for the scope of the project. For further information, see ISO 21500.
Most organizations have a well-established preference for a particular project methodology.
Regardless of which technology implementation method is selected, each depends on significant
amounts of prior work in:
— developing records controls (see ISO 15489-1);
— identifying configuration models (Clause 7); and
— defining training and change management needs (see Clauses 8 and 9)
See Annex A for further information on this topic.
5.2 Defining stakeholders
Implementing a software for managing records can involve many different professionals both internal
and external to an organization. Identifying these stakeholders, their expectations, and determining
their role is integral to successful implementation.
Internal stakeholders may include:
— project managers who may not always need specific records experience, but may specialize in
project management itself;
— IT professionals who may be responsible for technical deployment of software, end-user
assistance, etc.;
— senior management who are concerned with strategic direction, project progress against timelines,
deliverables and budget;
— individual business unit managers who are required to assign user resources at particular stages of a
project, for example when requiring business input into the design of the records controls, determining
user requirements or when any technology implementation is affecting their business area;
— legal professionals who can be required to assist in contract negotiations as well as ensuring that
legal requirements for the business are adequately met in the software; and
— user/business representatives who are required to interact with the software and be affected by its
implementation.
External stakeholders may include:
— clients or customers who may be impacted by changed user experience and technology use;
— business service providers who may have their interaction with the organization changed;
— auditors or other professional service providers who may require independent access to systems; and
— external software vendors who may be involved in software development or configuration.
Strategies for engaging with stakeholders should be devised. These may include involvement in product
selection, input into configuration decisions and user acceptance testing.
6 Determining and managing functional requirements
6.1 Developing functional requirements
Functional requirements specify the functionality that the selected software should provide. They
describe what should be done at present and what developments are desirable into the future.
Functional requirements should be developed, or selected, to reflect business activities and end-user
services in addition to technical requirements, as a tool to evaluate and select technology. Work process
analysis and business analysis may be required to establish the broader organizational functional
requirements which are appropriate.
Functional requirements should be formally defined. They should include key records concepts and
processes and may include technical requirements in terms of data, system performance, security and
maintainability requirements for the system. All requirements should be defined at a level of detail
which is sufficient for system design or selection to proceed. All requirements should be measurable
and testable and closely linked to business needs and records requirements.
Defining the functional requirements for an organization should reference any jurisdictional work
that has already been done which will minimize the time and effort required to develop organization-
specific functional requirements. Where a jurisdiction has a product certification scheme for software
for managing records,. an organization can assume that any certified software product will meet the
claimed functional requirements. As organizations may have other requirements which need further
configuration or additional software functionality, it may be necessary to ensure that the software still
meets the certification criteria.
Selecting software that creates or manages digital records should be done in line with defined
functional requirements. For a set of model and minimum functional requirements for managing digital
records, including digital records in business systems, see ISO 16175-1.
6.2 Considerations for defining functional requirements
Software can be used to support records processes and principles in different ways. In some cases,
functionality to manage records can be built into key business applications. Alternatively, independent
software for managing records may be required in the organization. The type of software needed
should be determined strategically and should be conformant with a broader enterprise information
architecture.
Functional requirements should not only consider records specific requirements but also seek to assess:
— user interface or how the user experiences the software;
— capability of the software to interface or integrate with existing key organizational business
software;
8 © ISO 2020 – All rights reserved

— capability to effectively manage import and export of records and metadata;
— capability to trace the development of the current state of the record over time, such as when it was
changed, by whom, what was changed and previous values; and
— where the software is positioned in relation to market trends.
Functional requirements are usually rated by importance – for example, as mandatory, conditional
or optional. The range, level of depth and level of obligation of functional requirements should be
determined according to the organizational records requirements.
6.3 Managing functional requirements
In an organization, functional requirements for records may be formed as a standard, guidance or
manual. It is possible to re-use already existing functional requirements for different types of software.
Functional requirements can:
— be the source of criteria for evaluating software's capability to satisfy the organization's records
requirement;
— contribute to development of use cases tailored to organizational requirements;
— contribute to development of test cases or test scripts against which to evaluate the software in
demonstrations;
— contribute to the enterprise information architecture by providing a model that maps the strategy
for implementation of software for managing records, including the migration paths and integration
to existing software;
— be expressed as a report recommending overall software design components;
— identify future requirements to enhance interoperability between software; and
— identify implications for licensing and ongoing maintenance.
Functional require
...

SPÉCIFICATION ISO/TS
TECHNIQUE 16175-2
Deuxième édition
2020-10
Information et documentation —
Processus et exigences fonctionnelles
applicables aux logiciels de gestion
des documents d'activité —
Partie 2:
Recommandations pour le choix, la
conception, la mise en oeuvre et la
maintenance des logiciels gérant des
documents d’activité
Information and documentation — Processes and functional
requirements for software for managing records —
Part 2: Guidance for selecting, designing, implementing and
maintaining software for managing records
Numéro de référence
©
ISO 2020
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2020
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, 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, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2020 – Tous droits réservés

Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Évaluation du cadre et du contexte organisationnels . 2
4.1 Généralités . 2
4.2 Maturité de l'organisme en matière de gestion des documents d'activité . 2
4.3 Mesures de contrôle pour la gestion des documents d'activité . 3
4.4 Environnement technique. 3
4.4.1 Généralités . 3
4.4.2 Environnement papier . 3
4.4.3 Environnement numérique . 4
4.4.4 Environnement hybride. 6
4.5 Définition du périmètre et des ressources du projet . 6
5 Détermination d'une méthodologie de projet . 8
5.1 Généralités . 8
5.2 Définition des parties prenantes . 8
6 Détermination et gestion des exigences fonctionnelles . 9
6.1 Élaboration des exigences fonctionnelles . 9
6.2 Facteurs à prendre en compte pour la définition des exigences fonctionnelles .10
6.3 Gestion des exigences fonctionnelles .10
7 Détermination de la configuration .11
7.1 Généralités .11
7.2 Importance de la documentation des décisions de configuration .11
7.3 Décisions en matière de configuration — Domaines de configuration.12
7.3.1 Généralités .12
7.3.2 Agrégation de documents d'activité .13
7.3.3 Agents (utilisateurs) .13
7.3.4 Processus métier.14
7.3.5 Référentiel de métadonnées pour la gestion des documents d'activité .14
7.3.6 Plans de classement fonctionnel .15
7.3.7 Règles d'accès et d'habilitation .15
7.3.8 Règles de conservation .15
7.3.9 Interface utilisateur .15
7.3.10 Degré d'automatisation qui sera pris en charge .16
7.3.11 Autres outils d'automatisation pouvant être utilisés .16
7.3.12 Métadonnées du processus documentaire pouvant être capturées
automatiquement .16
7.3.13 Intégration nécessaire avec d'autres logiciels métier existants .16
7.3.14 Règles spécifiques aux documents d'activité applicables .17
8 Détermination des exigences de migration et de conversion des documents d'activité .17
9 Communication, formation et gestion des changements .18
9.1 Généralités .18
9.2 Communication .18
9.3 Exigences du programme de formation .18
9.4 Préparation à la gestion des changements .19
9.5 Évaluation et examen .20
10 Examen, suivi et appréciation post-mise en œuvre .20
10.1 Examen post-mise en œuvre .20
10.2 Surveillance.21
10.3 Évaluation .21
Annexe A (informative) Aspects à prendre en compte pour l'établissement d'une
méthodologie de mise en œuvre d'un logiciel gérant des documents d'activité .23
Bibliographie .25
iv © ISO 2020 – Tous droits réservés

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/ iso/ fr/ avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 46, Information et documentation,
sous-comité SC 11, Archives/Gestion des documents d'activité.
Cette seconde édition de l'ISO/TS 16175-2 annule et remplace l'ISO 16175-2:2011 et l'ISO 16175-3:2010,
qui ont fait l'objet d'une révision technique.
Les principales modifications par rapport à l'édition précédente sont les suivantes:
— les exigences fonctionnelles pour les logiciels qui étaient précédemment fournies dans
l'ISO 16175-2:2011 et l'ISO 16175-3:2010 ont été mises à jour et consolidées;
— les recommandations relatives à la mise en œuvre des logiciels pour les documents d'activité
numériques qui étaient précédemment fournies dans les trois parties de l'édition précédente de la
série ISO 16175 ont été mises à jour et consolidées;
— dans une version mise à jour, du contenu générique relatif à la mise en œuvre des systèmes
documentaires (à la fois numériques et analogiques), qui était précédemment fournis dans
l'ISO/TR 15489-2:2001 maintenant annulée, a été inclus.
Une liste de toutes les parties de la série ISO 16175 se trouve sur le site web de l'ISO.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www .iso .org/ fr/ members .html.
Introduction
Tous les organismes ont au moins un système documentaire. Les systèmes documentaires sont
des systèmes d'information qui capturent et gèrent des documents d'activité et qui en assurent
l'accessibilité dans le temps. Les systèmes documentaires peuvent contenir des éléments techniques,
tels que des logiciels, et des éléments non techniques tels que des politiques, procédures et agents.
Les systèmes documentaires, au sens général du terme, incluent les politiques, processus, logiciels et
personnes qui utilisent et gèrent des documents d'activité. Les systèmes documentaires se déclinent
en diverses variantes: dans des systèmes papier, dans des logiciels spécialement conçus pour remplir la
fonctionnalité de gestion des documents d'activité, ou sous la forme de logiciels métiers qui capturent
et gèrent des documents d'activité. Le présent document se concentre sur la gestion des documents
d'activité dans un environnement numérique, utilisant des logiciels, mais les principes et aspects
généraux qui y sont traités s'appliquent à tout type d'environnement.
La présente Norme internationale n'établit aucune distinction entre les applications logicielles utilisées
pour répondre à tout objectif organisationnel et les applications qui sont spécifiquement destinées
et conçues pour gérer des documents d'activité. Les premières englobent, par exemple, les systèmes
et applications de gestion de contenu d'entreprise qui, entre autres fonctionnalités, permettent la
création de documents d'activité, tels que les systèmes de gestion de contrats, les systèmes de gestion
de dossiers ou les systèmes transactionnels. Le terme «logiciel gérant des documents d'activité» est
donc ici employé afin de couvrir la totalité des applications qui gèrent des documents d'activité dans le
cadre de leur fonctionnement usuel. L'hypothèse retenue est que toutes les applications métier génèrent
des données qui devront servir de preuve d'activité opérationnelle à des fins de référence ultérieure et
qui, entre autres, devront créer, stocker et gérer des documents d'activité, soit à l'aide de leurs propres
fonctionnalités internes, soit dans le cadre d'une utilisation combinée avec d'autres applications.
Les Articles 4 et 5 donnent des recommandations relatives à l'évaluation du contexte de l'organisme
et sur la portée d'un projet de mise en œuvre d'un logiciel gérant des documents d'activité. Les
Articles 6 à 8 fournissent des recommandations relatives à l'identification des exigences relatives
aux fonctionnalités du logiciel y compris celles concernant la conversion et la migration. L'Article 9
fournit des recommandations relatives à la communication, la formation et la gestion des changements.
L'Article 10 fournit des lignes directrices relatives à l'examen postérieur à la mise en œuvre.
L'ISO 16175-1 fournit un ensemble d'exigences fonctionnelles et de recommandations associées relatives
aux logiciels gérant des documents d'activité.
vi © ISO 2020 – Tous droits réservés

SPÉCIFICATION TECHNIQUE ISO/TS 16175-2:2020(F)
Information et documentation — Processus et exigences
fonctionnelles applicables aux logiciels de gestion des
documents d'activité —
Partie 2:
Recommandations pour le choix, la conception, la mise
en oeuvre et la maintenance des logiciels gérant des
documents d’activité
1 Domaine d'application
Le présent document fournit des recommandations pour la prise de décision et les processus concernant
le choix, la conception, la mise en œuvre et la maintenance de logiciels gérant des documents d'activité,
conformément aux principes spécifiés dans l'ISO 15489-1.
Le présent document s'applique à tout type de système documentaire soutenu par un logiciel, y compris
les documents d'activité papier gérés par un logiciel, mais se concentre plus spécifiquement sur les
logiciels gérant des documents d'activité numériques.
Le présent document fournit des recommandations à l'attention des professionnels des documents
d'activité responsables du choix, de la conception, de la mise en œuvre et de la maintenance des systèmes
qui gèrent des documents d'activité à l'aide de divers logiciels, ou qui y participent. Il peut également
apporter une aide aux professionnels des technologies de l'information tels que les architectes/
concepteurs de solutions, les décideurs responsables des achats de technologies de l'information, les
analystes métiers, les propriétaires de processus métier et les développeurs et testeurs de logiciels
cherchant à appréhender les exigences relatives aux documents d'activité.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).
ISO 30300, Information et documentation — Systèmes de gestion des documents d'activité — Principes
essentiels et vocabulaire
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l'ISO 30300 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:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse http:// www .electropedia .org/
4 Évaluation du cadre et du contexte organisationnels
4.1 Généralités
Les différents organismes ont leur propre culture, ce qui a généralement une incidence sur l'approche
qu'ils adoptent pour gérer des documents d'activité. Cette culture s'inscrit dans le contexte
organisationnel. Exemples de facteurs qui affectent la culture de l'information d'un organisme:
— les valeurs, attitudes et comportements des utilisateurs de l'organisme;
— l'environnement technique; et
— les exigences sociétales et organisationnelles, y compris la législation et/ou la règlementation, les
normes et les politiques associées contenant des exigences relatives à la gestion des documents
d'activité et à la conformité générale.
La culture organisationnelle influe sur les décisions relatives au choix et à la mise en œuvre des
systèmes et logiciels gérant des documents d'activité. Lorsqu'un organisme dispose d'un cadre défini
pour la gouvernance de l'information, il convient que le système de gestion des documents d'activité
soit intégré au cadre de gouvernance de l'information.
Si le logiciel gérant des documents d'activité prend en charge des processus partagés par plusieurs
organismes, il convient de tenir compte, pour chaque organisme des facteurs relatifs à la culture de
l'information. Il convient que le choix et la conception du logiciel gérant des documents d'activité
répondent aux besoins de chaque organisme. Il convient d'affecter clairement les responsabilités et
la propriété pour la gestion de systèmes multiorganisationnels et de définir d'un commun accord les
droits sur la gestion des documents d'activité créés dans ce logiciel partagé.
Il convient que le choix et la conception du logiciel gérant des documents d'activité dans un cadre
organisationnel qui définit les politiques et responsabilités à mettre en œuvre, et les éléments
d'outils de contrôle pour la gestion des documents d'activité nécessaires à la définition du périmètre
du projet. Il convient de tenir compte des aspects suivants au cours des phases de planification de
toute mise en œuvre:
— maturité de l'organisme en matière de gestion des documents d'activité;
— mesures de contrôle pour la gestion des documents d'activité;
— environnement technique; et
— définition du périmètre et des ressources du projet.
4.2 Maturité de l'organisme en matière de gestion des documents d'activité
L'évaluation de la maturité de l'organisme en matière de gestion des documents d'activité permet
d'orienter le choix, la conception et la mise en œuvre de logiciels gérant des documents d'activité.
L'exécution d'une telle évaluation permet de comparer les progrès accomplis au fil du temps et d'évaluer
les approches parmi des organismes similaires.
Les éléments suivants contribuent à évaluer la maturité d'un organisme en matière de gestion des
documents d'activité:
— si les responsabilités stratégiques de gestion des documents d'activité font partie des prérogatives
de la direction;
— si les documents d'activité et leur gestion sont considérés comme des composantes explicites de la
gouvernance de l'information;
— si une fonctionnalité documentaire est incluse comme composant de base de l'architecture
d'information d'entreprise soutenant le développement et le déploiement technologiques;
2 © ISO 2020 – Tous droits réservés

— le niveau auquel revient la responsabilité de trouver des ressources, d'appliquer et de suivre la
conformité aux principes de gestion des documents d'activité;
— la disponibilité d'utilisateurs formés et d'utilisateurs opérationnels pour concevoir, mettre en
œuvre et assurer la maintenance des logiciels gérant des documents d'activité;
— la culture de l'organisme et l'étendue des connaissances relatives aux responsabilités de création et
de gestion des documents d'activité au sein de l'organisme;
— les politiques, normes et recommandations décrivant les responsabilités et obligations en matière
de documents d'activité qui ont été développées pour l'organisme, qu'elles soient ou non à jour et
conformes ou non aux exigences de la juridiction compétente;
— si les exigences relatives aux documents d'activité ont été incorporées dans les cadres de gouvernance
de l'information et dans toutes les politiques, normes et lignes directrices applicables de l'organisme
(par exemple, confidentialité, sécurité de l'information ou reprise après sinistre);
— si des documents d'activité ont été liés à des évaluations des risques organisationnels et/ou
fonctionnels;
— si les principaux contrôles pour la gestion des documents d'activité sont à jour et s'ils sont à la
disposition des utilisateurs;
— la nature des systèmes documentaires en place;
— les liens entre les systèmes documentaires existants; et
— le type d'assistance proposée aux utilisateurs afin de comprendre leurs responsabilités en matière
de documents d'activité.
4.3 Mesures de contrôle pour la gestion des documents d'activité
Les systèmes documentaires peuvent être conçus de différentes manières pour soutenir l'activité,
et plusieurs systèmes documentaires peuvent coexister au sein de l'organisme dans son ensemble.
Il convient, dans la mesure du possible, de concevoir les mesures de contrôle pour la gestion des
documents d'activité au niveau organisationnel afin qu'elles puissent être appliquées de façon homogène
à l'ensemble des documents d'activité sans imposer à l'organisme l'utilisation d'une application
logicielle unique. Il convient de développer les mesures de contrôle pour la gestion des documents
d'activité identifiées dans l'ISO 15489-1:2016, Article 8, avant toute mise en œuvre d'un logiciel gérant
des documents d'activité spécifique.
Les mesures de contrôle développées au niveau de l'organisme peuvent être utilisées pour développer
des mesures de contrôle plus spécifiques, qui peuvent prises en charge par un logiciel gérant des
documents d'activité à un niveau restreint, par exemple, pour les contrôles s'appliquant à une partie
de l'organisme, ou faisant référence à une fonction spécifique. Les mesures de contrôle au niveau de
l'organisme peuvent former un modèle de conception à partir duquel les éléments spécifiquement
adaptés au périmètre de la mise en œuvre du logiciel peuvent être extraits ou développés en détail si
nécessaire.
4.4 Environnement technique
4.4.1 Généralités
Les paragraphes suivants concernent des environnements techniques courants dans lesquels sont
déployés des logiciels gérant des documents d'activité.
4.4.2 Environnement papier
Les systèmes documentaires papier sont souvent organisés en fichiers qui regroupent physiquement
des documents représentant les transactions de l'organisme de façon collective, de manière à en refléter
la formation. Les fichiers papier sont habituellement gérés et accessibles par des registres et des index
qui sont souvent automatisés à l'aide de logiciels.
4.4.3 Environnement numérique
4.4.3.1 Généralités
Nombre d'organismes évoluent aujourd'hui dans un environnement numérique. Bien que certains
documents d'activité papier puissent encore être créés ou reçus, ceux-ci sont convertis au format
numérique à l'aide de processus de numérisation, et les documents ainsi numérisés sont ensuite
incorporés dans le système documentaire en vue de leur traitement. Pour des recommandations sur la
numérisation, voir l'ISO/TR 13028.
Dans cet environnement, la principale préoccupation consiste à déployer un logiciel qui transpose à
des documents d'activité numériques les caractéristiques des documents d'activité probants (c'est-à-
dire authenticité, fiabilité, intégrité et utilisabilité). Il est aussi généralement important de permettre
d'étendre la durée des documents d'activité numériques concernés (y compris leurs métadonnées)
au-delà de la durée de vie d'un logiciel particulier. Dans le même temps, il convient d'identifier les
ressources permettant de soutenir la gestion des documents d'activité numériques.
Il est important que la continuité numérique soit maintenue. Un logiciel a, en général, une durée de
vie pratique d'environ 5 à 10 ans avant de subir une mise à niveau majeure ou un remplacement. La
question de la continuité numérique implique de tenir compte de différents aspects:
— les données qu'il est nécessaire de considérer comme un document d'activité peuvent ne plus être
stockées et accessibles dans une forme documentaire reconnue. Les champs de données apportant
la preuve des transactions constituent des documents d'activité. Ces systèmes sont souvent des
applications métier qui doivent évaluer la manière de préserver la preuve de l'activité. Il arrive
parfois que des métadonnées structurées, définies pour certains secteurs d'activité spécifiques,
puissent informer sur la configuration des éléments de métadonnées. Pour évaluer la mise en œuvre
des exigences relatives aux documents d'activité dans de tels environnements, il est essentiel de
déterminer:
— ce qui constitue la preuve de l'activité;
— de quelle manière s'assurer qu'elle reste reproductible lorsqu'elle est présentée à un utilisateur
à un moment donné;
— les détails relatifs aux modifications; et
— quand le contenu des champs de données a été modifié et par qui.
Il convient d'utiliser le processus d'évaluation pour évaluer ces aspects. Pour des recommandations
supplémentaires concernant l'évaluation, voir l'ISO/TR 21946.
— certaines applications métier permettent de stocker des documents dans les limites de leur logiciel.
Les documents peuvent constamment évoluer, alors qu'il convient que les documents d'activité
soient protégés contre les modifications non autorisées afin de garantir leur intégrité de preuve.
— les documents peuvent être constitués de données qui peuvent être stockées séparément et
représentées au besoin dans une vue unique (un document). La capacité à stocker séparément des
données et du contenu désagrégé, le tout distinctement du support, suppose de mettre en place des
mesures de contrôle pour la gestion des documents d'activité.
— des outils de séquencement de tâches peuvent être utilisés pour soutenir les autorisations et
approbations. Ces outils utilisent souvent des liens et des notifications par e-mail, et tiennent lieu
de connecteurs entre des logiciels spécifiques. Il peut être nécessaire de retracer sous forme de
documents d'activité les définitions des séquences de tâches elles-mêmes, tout comme les résultats
de ces séquences de tâches et en particulier les approbations et autorisations.
4 © ISO 2020 – Tous droits réservés

Il convient que tous les projets visant à faciliter la transition du papier au numérique comprennent de
façon exhaustive la législation, la réglementation et les règles concernant:
— les mécanismes de déclaration d'authenticité, tels que les signatures électroniques;
— les exigences pour définir des processus adéquats afin de garantir l'admissibilité juridique des
copies numériques de documents d'activité analogiques; et
— les exigences juridictionnelles pour conserver certains documents d'activité physiques après leur
numérisation.
4.4.3.2 Environnement de «cloud computing»
Les services cloud sont de plus en plus utilisés pour fournir un stockage et un accès flexible aux
logiciels et aux documents d'activité numériques. Il existe plusieurs options d'achat et de déploiement
de services cloud. Les options incluent le logiciel en tant que service, le logiciel avec une interface
utilisateur accessible depuis un navigateur et le stockage des documents d'activité dans le cloud. Pour
les documents d'activité, cette approche «en tant que service» implique généralement le stockage de
documents d'activité numériques sur des serveurs externes à l'organisme. À mesure qu'émergent des
produits conçus pour l'environnement cloud, les fonctionnalités des logiciels gérant des documents
d'activité sont de plus en plus disponibles sous la forme d'un service. À l'heure actuelle, cela se résume
habituellement à un accès à un ensemble unique de fonctionnalités ou de logiciels propriétaires qui
fournissent des fonctionnalités de gestion documentaire. À terme, il est prévu que des offres de
fonctionnalités de plus en plus restreintes seront proposées en tant que services, ce qui permettra
des mises en œuvre plus intelligentes pour développer les processus et fonctionnalités documentaires
nécessaires à partir de plusieurs applications de services différentes.
Dans cet environnement, au-delà des problèmes liés à l'authenticité et à la durabilité, les organismes
doivent tenir compte des règles juridictionnelles concernant la souveraineté des données, la sécurité
des réseaux et le développement de cadres contractuels et techniques adéquats afin de garantir un
niveau de service approprié. Au moment de la création des accords de service, il est nécessaire de
prendre en compte les exigences relatives à la fin du service et à la migration d'une plate-forme à une
autre. Des outils d'évaluation des risques soutenant les décisions relatives à l'adoption de services basés
sur le cloud sont disponibles dans diverses juridictions.
4.4.3.3 Logiciels collaboratifs accessibles depuis un navigateur web
Les logiciels gérant des documents d'activité peuvent se présenter sous la forme de logiciels accessibles
depuis un navigateur web que les organismes déploient à la demande de manière flexible, à mesure
qu'ils s'agrandissent et que leurs exigences évoluent. Ces logiciels peuvent impliquer plusieurs agents,
y compris ceux externes à l'organisme, par exemple des fournisseurs ou prestataires de services. Les
deux parties utilisent le même logiciel pour documenter les transactions et les communications. Pour
les documents d'activité gérés dans cet environnement technologique, les aspects suivants sont à
prendre en compte:
— Qui est responsable de la gestion des documents d'activité probants?
— Qui est le propriétaire du document d'activité?
— Qui est le gardien désigné du système, chargé de gérer des contrôles tels que les autorisations de
sécurité, les droits d'accès, etc.?
— Le système peut-il prendre en charge l'extraction des documents d'activité qui ont été incorporés
dans différents systèmes organisationnels?
— Qu'advient-il des données à la fin des contrats? Les contrats peuvent porter sur la licence logicielle,
sur le stockage, sur des services ou sur l'activité opérationnelle.
Comme dans le cas des systèmes basés sur le cloud, il convient de tenir compte des règles juridictionnelles
relatives à la souveraineté des données, à la sécurité du réseau et aux cadres contractuels et techniques
adéquats pour garantir des niveaux de service appropriés.
4.4.4 Environnement hybride
Les documents d'activité sont de plus en plus créés dans un format numérique. La possibilité d'imprimer
ces documents sur support papier et de renouer avec l'environnement papier est parfois préconisée
comme une étape transitoire avant le passage à des environnements de gestion davantage axés sur
le numérique. Lorsque des documents d'activité sont reçus au format papier mais que l'organisme y
répond sous une forme numérique, l'environnement est dit «hybride» puisqu'il contient à la fois des
documents papier et des documents d'activité numériques.
Différentes approches sont adoptées dans cet environnement complexe. Chaque approche implique des
compromis qu'il convient d'évaluer en fonction des besoins spécifiques de l'organisme. Les approches
sont les suivantes:
— maintenir des systèmes de documents d'activité numériques et de documents papier distincts
(par exemple, gérer les e-mails et leurs pièces jointes dans le système de messagerie, et gérer les
fichiers papier dans un autre système). Si possible, il convient d'appliquer des mesures de contrôle
uniformes pour la gestion des documents d'activité comme les plans de classement fonctionnels
entre les deux environnements techniques, afin d'éviter aux utilisateurs d'avoir à accéder à deux
systèmes distincts, voire plus;
— créer dans le logiciel une structure «de référence» qui établit des conteneurs logiques uniques
référençant à la fois les documents d'activité numériques et les documents d'activité papier, en
identifiant l'emplacement et le format du document sous la forme d'un type de support distinct.
4.5 Définition du périmètre et des ressources du projet
L'examen des questions abordées aux 4.1 à 4.4 permet de définir le périmètre du projet. Un logiciel
gérant des documents d'activité peut être mis en œuvre afin de répondre à différentes exigences, allant
de la prise en charge de documents d'activité dans un logiciel métier spécifique à la mise en œuvre
d'un logiciel gérant des documents d'activité venant à l'appui de tout ou partie de l'organisme. Il
convient de définir les limites du projet.
Il convient de définir dans un premier temps les limites du projet par rapport à l'activité.
— Le logiciel est-il destiné à soutenir l'ensemble de l'organisme ou seulement des parties de l'organisme?
Spécifier les fonctions métier, les activités ou les sections organisationnelles à inclure dans le projet.
— Les processus métier existants ont-ils vocation à être automatisés, ou est-il possible de redéfinir les
processus métier ayant une incidence sur la création et la tenue à jour des documents d'activité?
— Comment le logiciel va-t-il être utilisé? Par exemple, s'agira-t-il d'un logiciel autonome, des
documents d'activité seront-ils incorporés dans un système métier existant/un nouveau système
métier planifié, ou une interface entre le logiciel gérant des documents d'activité spécifique et les
systèmes métier sera-t-elle utilisée?
— Qui utilisera et interagira avec le système? Quelles contraintes ou opportunités cela représente-t-il?
Une fois les limites établies, il est essentiel de connaître les fonctions métier et les activités entreprises
dans les limites du périmètre du projet. Cela implique:
— d'entreprendre un processus d'évaluation dont le périmètre est défini par les limites du projet.
Voir l'ISO/TR 21946 pour des recommandations sur les processus d'évaluation des documents
d'activité. Le cas échéant, les résultats des processus d'évaluation précédemment effectués au sein
de l'organisme peuvent être réutilisés; et
6 © ISO 2020 – Tous droits réservés

— d'identifier les fonctions métier ou les logiciels gérant des documents d'activité actuellement utilisés
et qui peuvent nécessiter une intégration, une mise hors service ou une autre option de conception
en faveur de tout nouveau logiciel conçu (voir l'Article 6).
Lors de la définition du périmètre d'un projet, il convient d'entreprendre une évaluation initiale des
ressources et des capacités pouvant affecter le projet. Lorsque l'évaluation porte sur un logiciel gérant
des documents d'activité, elle peut inclure:
— Le contexte opérationnel: certains organismes peuvent être dans l'obligation de se conformer
aux orientations stratégiques établies par d'autres parties, par exemple des ministères peuvent
être contraints de respecter des règles applicables à l'échelle de leur juridiction. Ces orientations
stratégiques peuvent affecter les options de mise en œuvre disponibles. Par exemple, une juridiction
peut exiger l'utilisation d'un logiciel libre («open source») ou l'utilisation d'un cloud gouvernemental
privé, une direction peut avoir déjà mis en place une politique privilégiant l'utilisation du cloud
ou décider d'utiliser le logiciel de plate-forme existant, ou un logiciel spécifique peut être dicté
par d'autres achats effectués par l'organisme. Ces décisions de gestion délimitent les orientations
technologiques que peut prendre l'organisme et peuvent, à leur tour, définir les paramètres selon
lesquels pourra être mis en œuvre le logiciel gérant des documents d'activité.
— L'infrastructure informatique et les réseaux: un logiciel gérant des documents d'activité, en
particulier s'il intègre des images numérisées, peut consommer énormément de ressources si
l'organisme ne dispose pas de l'infrastructure réseau nécessaire pour faire face au volume et à la
taille d'informations supplémentaires. Des facteurs tels que la vitesse du réseau, la bande passante,
la capacité de stockage, la résolution disponible sur les écrans des utilisateurs, etc., sont à prendre
en compte.
— L'évolutivité du logiciel: l'évolutivité est la capacité du logiciel, du réseau ou du processus à
traiter un volume de travail croissant ou à élargir son potentiel de manière à s'adapter à cette
croissance. L'étendue à laquelle il peut être nécessaire de «faire monter en puissance» le logiciel
gérant des documents d'activité en vue d'un déploiement plus vaste ou d'un déploiement à l'échelle
de l'organisme doit être prise en compte et planifiée dès les premières phases de mise en œuvre du
logiciel, afin de répondre aux besoins métier de l'organisme. Il est fréquent que les environnements
d'entreprise varient sensiblement pendant le développement ou le cycle de vie de documents
d'activité ou de logiciels métier spécifiques. Il convient que le logiciel gérant des documents
d'activité soit suffisamment souple pour s'adapter à l'évolution des besoins métier et des exigences
documentaires.
— Les performances du logiciel: comme tous les systèmes technologiques, il est nécessaire qu'un
logiciel gérant des documents d'activité définisse des paramètres de performances logicielles
appropriés. Les indicateurs de performances les plus significatifs sont le temps de réponse et les
débits de traitement des données. Il est attendu que le logiciel se comporte d'une manière prévisible
en cas d'évolution de ces variables. L'établissement de critères de performances appropriés pour le
système logiciel permet de définir les ressources technologiques nécessaires pour assurer le bon
fonctionnement des processus métier dont les performances revêtent une importance stratégique.
Afin de répondre aux exigences documentaires de l'organisme, il convient de développer ces critères
de performances en tenant compte des exigences fonctionnelles ainsi que des exigences relatives
aux métadonnées des processus documentaires et des mesures de contrôle pour la gestion des
documents d'activité. (D'autres aspects à cet égard sont documentés dans l'ISO/TR 14105).
— Le budget: il convient d'identifier tous les coûts associés à la mise en œuvre du logiciel. Cela inclut
les coûts associés au choix et à la configuration initiale, ainsi qu'à la gestion des changements et à la
formation dispensée pour la mise en œuvre initiale. Il convient d'identifier les coûts récurrents et
de les répartir au-delà du cadre spécifique de l'allocation du budget de projet. Ces coûts englobent la
formation continue et l'assistance.
— Les compétences: la mise en œuvre d'un logiciel gérant des documents d'activité implique:
— des aptitudes et compétences organisationnelles en lien avec l'analyse de rentabilité;
— une compréhension du contexte organisationnel et de la maturité de l'organisme dans le
domaine documentaire;
— une identification et une évaluation des produits technologiques disponibles;
— des compétences techniques pour la mise en œuvre et l'administration du logiciel;
— des compétences documentaires spécialisées pour concevoir et mettre en œuvre des mesures
de contrôle documentaire au sein du logiciel; et
— des ressources importantes en matière de gestion des changements.
5 Détermination d'une méthodologie de projet
5.1 Généralités
La mise en œuvre d'un projet visant à introduire un logiciel gérant des documents d'activité peut être
entreprise à des niveaux de complexité variables. Il convient de déterminer une méthodologie de mise
en œuvre adaptée au périmètre du projet et à celui du logiciel mis en œuvre.
Une méthodologie de gestion de projet est couramment utilisée pour gérer le projet lui-même. Il
convient que la méthodologie choisie soit adaptée au périmètre du projet. Pour plus d'informations, voir
l'ISO 21500.
La plupart des organismes expriment une pré
...