La mise en place d’un système de « document & records management » est un projet et un investissement important pour une organisation. Il est donc essentiel que le lancement d’un tel projet soit bien préparé, sans quoi le projet sera soit un échec soit rencontrera des difficultés difficiles à gérer qui pénaliseront le projet pendant plusieurs mois, voire années. En 2010, la firme Gartner a évalué qu’un tiers des projets de ce type allaient être un échec.

Un système de document & record management permet de gérer électroniquement des documents (ou autres types d’informations) et des procédures. L’outil, bien qu’important, n’est donc qu’un soutien à l’informatisation de ces deux composants, il est donc secondaire. Un travail important d’analyse et d’organisation en amont est requis pour maximiser les chances de succès d’un tel projet.

Sur la base de notre expérience et des recherches effectuées dans le domaine, voici 10 recommandations pour partir du bon pied.

1. Soutien fort de la direction

C’est bateau vous direz ! Quel projet informatique ne requiert pas un soutien fort de la direction ? Vous avez raison. Mais un système de gestion documentaire a souvent un impact fort sur les utilisateurs car nombreux sont ceux qui manipulent du papier et qui vont devoir apprendre à manipuler des images numériques. Pas simple ! Un projet aussi important que l’implémentation d’un système de gestion documentaire à l’échelle de tout une organisation rencontrera inévitablement des obstacles et des difficultés, d’autant plus qu’il modifie la manière de travailler.

Par exemple, si un service concerné refuse de mettre ces documents dans le système, comment l’organisation réagit-elle ? L’équipe de projet peut-elle compter sur le soutien du management pour convaincre, voire imposer, l’adhésion du service au projet ?

Une organisation comporte de nombreux départements et services et gère de nombreuses activités. Tous ces services, toutes ces activités sont-elles concernées par la mise en place d’une application de gestion documentaire ? Se concentre-t-on sur les activités métiers de l’organisme ou également les activités de support ?

3. Définition du scope informationnel de l’application

Dans le cadre de ses activités et ses missions, un organisme reçoit et produit de nombreux documents qu’il lui faut gérer et conserver. Toutes ces informations doivent-elles être incluses dans le périmètre informationnel de l’application ou se concentre-t-on sur une ou plusieurs notions métiers de l’organisation ?

A titre d’exemple, au début des années 2000, l’ONSS a mis en place un système de gestion documentaire centré sur les documents relatifs aux employeurs, qui représentent le cœur de métier de l’ONSS (aujourd’hui, soit 10 ans plus tard, un projet est actuellement en cours pour étendre ce système à toute l’organisation et à tous les activités et documents ; ce délai a permis aux agents de l’ONSS de mieux appréhender ce type de système).

Le périmètre informationnel fixé, il faut identifier les types de documents que l’application doit pouvoir gérer : valeur des documents, besoin en termes de confidentialité, de droits d’accès et d’édition, archivage, … Quelles sont les sources de l’information ? Qui la consulte ? Quelles sont par conséquent les intégrations à réaliser ?

Rien de tel pour procéder à cet exercice qu’un groupe multidisciplinaire composé d’un représentant de chaque activité et services concernés ainsi que de juristes (et éventuellement des représentants de l’audit interne).

4. Identifier les besoins fonctionnels et non fonctionnels

Sur la base du scope business et du scope informationnel, il faut identifier les besoins fonctionnels pour les différents éléments de la chaîne de traitement documentaire (capture, gestion, description, archivage, diffusion, …), les intégrations à réaliser, les aspects de sécurité, de confidentialité, de volumétrie, …

Selon ces besoins, des modules fonctionnels ou des logiciels complémentaires au logiciel de gestion documentaire devront être acquis.

Trop souvent dans ce type de projet, les résultats attendus sont formulés en des termes très vagues ou trop flous pour la plupart des intervenants, tel que « le système doit permettre aux utilisateurs de travailler de manière plus efficace ».

Que signifie « efficace » pour les utilisateurs ? Est-ce une disponibilité plus rapide de l’information ? Dans ce cas, quel délai est-il acceptable ? Est-ce le rassemblement de nombreux informations en un seul endroit afin d’un avoir accès plus simplement ?

Lorsque l’ONVA a lancé son projet de gestion électronique des documents au début des années 2000, l’objectif était de répondre à tous les courriers entrants dans un délai de 30 jours.

De nombreux applications métiers gèrent et produisent des documents. Il faut donc positionner le système de gestion documentaire par rapport aux autres applications et à ces documents. Quel est le rôle du système de gestion documentaire ? Quels sont les fonctionnalités que toute application tierce délègue obligatoirement au système de gestion documentaire ? Y a-t-il des exceptions autorisées ?

De cette manière, chaque nouvelle application ou flux documentaire pourra s’intégrer harmonieusement avec le système de gestion documentaire en évitant les risques de création de silos d’informations.

Une organisation doit être mise en place pour soutenir le fonctionnement d’un système de gestion documentaire : cellule de scanning, centre de compétence, chambre postale, …

Au sein de cette organisation, des procédures claires doivent être définies. Par exemple : comment le courrier entrant dans l’organisme est-il traité ? Quels sont les workflows à implémenter pour la rédaction de documents sortants ? Quand un document doit-il être capturé dans le système ? Les workflows devront être clairement définis ainsi que le rôle de chaque intervenant.

Le nombre d’utilisateurs du système est également nécessaire pour bien dimensionner la solution informatique, au risque de rencontrer des problèmes de performance.

Un projet de gestion documentaire à l’échelle de toute une organisation représente un investissement et donc un risque important. Il est donc fondamental qu’il soit confié à des personnes disposant des compétences dans ce domaine, aussi bien au niveau du project management que des analystes. Idéalement, ces personnes (du moins une partie de l’équipe) auront déjà une expérience pratique en la matière.

Dans un second temps et en fonction du logiciel choisi ou sélectionné, des analystes, des développeurs et un architecte plus formé audit logiciel devront être recrutés et formés.

Afin d’éviter un bouleversement trop important de l’organisation et éviter un projet trop ambitieux dont les résultats concrets se font attendre, il est préférable, sur la base de la définition des besoins, d’identifier les sous-projets qui peuvent être implémentés de manière indépendante et de les prioritiser.

Il est préférable de commencer avec un projet dont les résultats concrets sont importants d’un point de vue métier et directement perceptibles par les utilisateurs afin de démontrer le bien-fondé de l’application.

Il est courant et normal que nombre d’intervenants dans ce type de projet n’aient qu’une connaissance vague ou imprécise de la gestion documentaire électronique. Cette situation engendre des incompréhensions, des difficultés durant l’organisation des interviews, des groupes de travail, faire naître des espoirs, etc.

Une fois les intervenants du projet identifiés, une formation est donnée pour rappeler les grands principes de la gestion documentaire, les fonctionnalités de ce type de systèmes, …

N’hésitez pas non plus à organiser une démo dans un autre organisme si vous avez des contacts. Du concret vaut souvent mieux qu’un long discours.