webleads-tracker

L’anti manuel GED dans les collectivités : comment rater son projet

L’anti manuel GED dans les collectivités : comment rater son projet

Avec l’accroissement de la dématérialisation des processus de travail, de plus en plus d’organisations se lancent dans des projets de gestion électronique de documents (GED) avec un succès parfois mitigé. Comment expliquer ce phénomène ? A travers un exemple théorique issu de plusieurs expériences de terrain, Sollan vous propose d’explorer les facteurs qui assurent l’échec d’un projet de GED.

 

Etape 1 : Acquérir une GED

Posons l’exemple d’une organisation publique d’une vingtaine de directions et quelques milliers d’agents, qui a acquis presque toute la panoplie d’outils nécessaires à la dématérialisation de la chaîne comptable, parmi lesquels, une GED, destinée à accueillir les documents dématérialisés. A priori, un besoin clair, une réponse appropriée. La DSI pilote le projet. Un outil de GED est acquis en 2010.
 
La DSI a pour ambition de se positionner dans une approche à long terme, elle est visionnaire. Elle veut une GED transversale, pour tout le monde, pour tous les documents de la collectivité. Pas un seul processus n’est précisément identifié puisque ce sont tous les processus qui sont concernés -nous reviendrons sur le processus-prétexte à l’acquisition de l’objet- mais dès 2010, la DSI exprime l’ambition de remplacer les serveurs bureautiques par la GED.
 
Chaque direction opérationnelle aura son propre espace collaboratif pour gérer ses documents d’activités. D’autres espaces collaboratifs, métiers, d’experts, de projet, permettront le travail collaboratif et transversal. L’objectif est défini par la DSI et les modalités d’atteinte cible ne sont pas envisagées.
 
 

Etape 2 : Utiliser la GED comme support de dématérialisation d’un processus complexe

Revenons maintenant au processus-prétexte, le processus budgétaro-comptable au sein de la collectivité. Pour rappel, il est le suivant : engagement juridique, engagement comptable, service fait / liquidation, mandatement, envoi des pièces comptables et de leurs pièces justificatives au Payeur, paiement. 
 
Depuis 2004, l’Etat incite à la dématérialisation des échanges entre l’ordonnateur (la collectivité publique) et le Payeur ; depuis la loi NOTRe du 7 août 2015, il a introduit une échéance réglementaire au 1er janvier 2020.
 
Il suffit de jeter un œil à un référentiel des pièces justificatives comptables (PJ) pour comprendre que le processus comptable est un processus qui est nourrit par des centaines de sous-processus.
 
En effet, à chaque type de PJ correspond un processus métier qui suppose la production des pièces. 
 
Le processus comptable est composé de centaines de processus d’acquisition de pièces justificatives, produites pour les besoins comptables (exemple : facture) ou pour d’autres besoins mais nécessaire à l’appui d’un paiement ou d’une recette (exemple : délibération de l’organe délibérant, jugement d’un tribunal). 
 
Il y a :
  • les PJ produites en internes,
  • les PJ reçues de l’extérieur, 
  • les PJ mixtes (produites en internes, co-signées avec des partenaires, comme les conventions, les marchés), 
  • la dématérialisation duplicative et la dématérialisation native parmi laquelle les pièces produites par des applications métier tierces et les pièces issues des logiciels bureautiques, 
  • les pièces dont le caractère exécutoire doit être garanti, celles qui n’ont pas de caractère exécutoire, etc. ,

qui entrainent une grande variété des processus d’acquisition en GED différents.

 
Tous ces processus existent avec des pièces papier. Mais pour les transposer dans un univers dématérialisé au sein d’un processus support commun, on imagine bien la complexité que cela représente.
 
Et réussir à proposer des procédures informatiques et métier viables n’est pas exploiter l’ensemble des gisements d’optimisation en termes de rationalisation, d’harmonisation et d’amélioration de la qualité comptable.
 
D’ailleurs, en 2010, dans cette organisation publique, il n’y a pas de référentiel des PJ. La DSI a conscience qu’il faudra stocker des documents électroniques liés au processus comptable, mais lesquels ? pour quelle utilisation ? dans quels flux ? en relation avec quelles applications métiers ? selon quelles modalités d’échanges avec le logiciel financier ? avec quelles garanties de sécurité sur le cycle de vie des documents ? Il sera bien le temps de voir plus tard.
 
 

Étape 3 : Si cela ne fonctionne pas, passer à autre chose

Devant les difficultés à exploiter la GED pour la dématérialisation de la chaîne comptable, la DSI a donc commencé à faire pression sur les métiers pour mettre en œuvre le « reste ». C’est-à-dire, rappelons-le, vraiment tout le reste : rien moins que le remplacement des serveurs bureautiques.
 
Documentalistes et archivistes ont été sollicités, ceux-là mêmes qui collaboraient au projet de la dématérialisation comptable et qui étaient conscients ce que le « reste » impliquait, à savoir :
  • réaliser un travail de fourmi pour concevoir et définir toutes les règles de gestion pour des dizaines d’unités organisationnelles, une direction pouvant se diviser en services, en bureaux, en secteurs puis en pôles ;
  • imposer à tous sans exception des règles de nommage et l’utilisation de plans de classements structurés ;
  • accompagner le changement au plus près de milliers d’utilisateurs.
 
Autant dire qu’il n’y avait pas une équipe de records managers, qualiticiens, archivistes et documentalistes à mettre à plein temps sur le sujet, les deux premières compétences n’étant même pas présente dans l’organisation. 
 
La perspective de devoir concrétiser ce projet a eu un effet électrochoc sur la MOA. 3 ans après l’acquisition de la GED, la MOA, emmenée par une structure transversale rattachée à la direction générale des services, a pris l’initiative d’objectiver pour le top management, bercé dans l’illusion que la GED était la panacée universelle :
  • ce que la collectivité faisait vraiment de sa GED transversale depuis 3 ans,
  • l’effort à fournir pour en faire quelque chose dans un délai un tant soit peu raisonnable.
 
La démarche fut salutaire. Le remplacement des serveurs bureautiques a été repoussé sine die.  Des ressources furent renforcées sur un projet plus simple qui fut mis en production dans les mois qui suivirent et tout un travail de structuration et de pilotage du portefeuille de projets fut mis en place.
 
Quelles conclusions faut-il en tirer ?
 
Cet exemple est fort instructif. On peut en extraire quelques règles de base pour s’assurer qu’un projet de GED générera des coûts élevés, sur une longue durée et pour un résultat de faible qualité.
 
 

Les règles à suivre pour rater son projet de GED :

1/ Pour commencer, il y a des facteurs de contexte favorables. Idéalement, la DSI n’est pas très structurée et la gestion de projet est artisanale
En parallèle, le mode projet n’est pas maîtrisé par les métiers et les fonctions MOA ne sont ni vraiment identifiées ni reconnues. Le nec plus ultra, c’est une organisation qui a fait le choix de centrer sa DSI sur les missions de MOE sans intégrer l’absence de maturité de la MOA. 
 
2/ L’absence de Schéma directeur des systèmes d’information (SDSI) ou, s’il existe, de gouvernance du SDSI, est un facteur supplémentaire qui affranchit l’organisation de considérer le projet de GED transversale comme un portefeuille de projets hiérarchisés et qui prévient toute tentative de pilotage stratégique intégrant les dimensions techniques, organisationnelles et fonctionnelles.
 
Dans ce cas, la DSI sera bien la seule unité organisationnelle susceptible de piloter un projet de GED transversale puisqu’elle est la seule à avoir une vision d’ensemble des enjeux SI de l’organisation. Elle s’appuiera sur des compétences métier atomisées qui ne sont pas mises en cohérence entre elles.
 
3/ Une vision « idéologique » de la GED est également un plus. Les valeurs de collaboration, de modernité et d’efficacité portées par la GED pourront dès lors aveugler les acteurs du projet global, et notamment le management, sur les enjeux opérationnel et fonctionnel de la mise en œuvre des projets particuliers.
 
Forte de ce « mandat », la DSI devra avoir à cœur d’associer le moins possible le top management et les métiers.
 
4/ Sur le plan opérationnel, il conviendra d’éviter toute approche par processus. On risquerait de parvenir à faire un recensement des projets qui en découlent, ce qui serait prendre le risque de les évaluer (coûts / gains pour l’organisation) et, encore pire, de les hiérarchiser dans une optique de mise en œuvre opérationnelle. Ce serait, on le voit, le premier pas vers la constitution d’un portefeuille de projets GED voire d’une feuille de route de dématérialisation au sein de l’organisation.
 
Ainsi l’organisation pourra-t-elle commencer en toute méconnaissance de cause la mise en œuvre de sa GED transversale par la dématérialisation d’un processus très complexe, comme le processus budgétaro-comptable, sans tenter de monter en compétence progressivement sur un processus plus simple.
 
5/ Enfin, il faudra avoir acquis l’outil de GED le plus tôt possible dans le projet, sur la base d’un cahier des charges général et assez flou. Cela augmentera la probabilité d’acquérir un outil qui ne correspond pas réellement aux attentes métier avec comme conséquence de devoir, au choix, acquérir ultérieurement un autre produit, financer de nombreux développements spécifiques lourds à maintenir, réduire l’efficacité des processus métier pour les adapter aux contraintes de l’outil.
 
On aura compris que cet anti-manuel montre ce qu’il faudrait ne pas faire, ce qui n’indique pas nécessairement en négatif ce qu’il faut faire. 
En effet, une organisation ne peut pas poser comme condition de s’être structurellement réformée avant de lancer des projets informatiques. Les organisations sont en mouvement permanent pour s’adapter à l’évolution de leur environnement et certaines sont plus lentes à mouvoir que d’autres.
 
C’est une des raisons pour laquelle existent des sociétés qui proposent des prestations d’assistance à maîtrise d’ouvrage spécialisée. Chez Sollan par exemple, nous proposons une prestation d’assistance à l’élaboration de la feuille de route dématérialisation à partir d’une phase de collecte d’information et d’’inventaire des processus à dématérialiser. Les projets correspondants sont évalués, notés et hiérarchisés avec le client, les interdépendances sont analysées et intégrées dans des macro plannings. Enfin, les dispositifs techniques socles à acquérir sont identifiés. Ce, en proposant une stratégie de gestion des risques propre au contexte de l’organisation.
 
La difficulté reste dans la prise de conscience par une entité de son niveau de maturité et d’autonomie sur les enjeux stratégiques de SI, prise de conscience qui seule déclenchera une demande d’accompagnement.
 

 

Je m'inscris à la Newsletter mensuelle de Sollan

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ajouter un commentaire

CAPTCHA
Merci de nous aider à éviter les spams, en répondant à cette question. Par exemple, pour 1+3, saisissez 4 :
3 + 6 =
Trouvez la solution de ce problème mathématique simple et saisissez le résultat. Par exemple, pour 1 + 3, saisissez 4.