Réseaux sociaux,GED, Archivage, Collaboratifs, Workflow, Email, ce sont tous les mêmes !

Pour les amateurs de « fraicheur », ce billet aurait pu s’appeler « les chasseurs » ou plutôt « la différence entre le bon chasseur et le mauvais chasseur ».

La gestion de contenu parait souvent être un magnifique iceberg :

  • Au mieux, la simple question « j’ai besoin de gérer ces documents » ou « il faudrait gérer cette information » provoque la petite angoisse du « quel outil choisir ».
  • Au pire, on ne voit pas l’iceberg et la réaction se fait selon un affectif marketing sur les produits en vogues (j’ai vu mettre en place des sites collaboratif pour faire de la Ged lourde, ça coute au final …, plus cher que cela ne sert)

Dans tous les cas ce n’est pas simple, et une approche directe outil risque fort de se transformer en bac à sable de mûrissement. (ce qui je pense est bien, uniquement, pour permettre à la future équipe projet de challenger ce sujet, si le temps et les moyens sont là).
Une autre approche serait de raisonner en termes d’usages et de cycle de vie, et de comprendre les particularités des différentes familles d’outils.

Même si on peut considérer que les besoins en fonctionnalités sont en général les mêmes d’une organisation à une autre (Voir 80% des besoins).

Après tout, que cela soit pour l’email, la Gestion électronique de document, le collaboratif projet, le micro blog ou twitter-like, les réseaux sociaux, l’archivage probant et long terme, … , tous ces outils :

  • gèrent du contenu sous forme de message, ou sous forme de document,
  • permettent de capturer de l’information,
  • ont un moteur de règles de gestion simple (format, longueur, ..) voir évolué (workflow),
  • offrent des possibilités de retrouver de l’information,
  • s’appuient pour la majorité sur des référentiels ne serait-ce que pour classer les informations,
  • permettent « d’archiver » de façon simple (exports) ou évolué (archivage probant),
  • maintiennent un historique, pour certains des traces,
  • ont des niveaux de services, une sécurité et un niveau d’intégrité plus ou moins perfectionnée.

Une vue selon des briques fonctionnelles

Du coup si fonctionnellement, nous modélisons les grandes familles de traitement, chacun de ces outils de gestion de contenu s’appuient sur un enchainement de briques fonctionnelles que l’on peut formaliser selon le schéma suivant.

cycle_de_vie_documentaire_vue_fonctionnelle

Cette modélisation permet, de se poser quelques questions judicieuses comme “Quelles sont mes grands besoins et sur quelles briques vont-ils s’appuyer ?”:

  • Capture : Vais-je avoir en entrée de grand volume complexe d’information, de quel type (court, long, complexe), de quels formats, …
  • Gestion : Vais-je avoir à appliquer des traitements complexes, des workflows de validation, voir de pilotage d’ERP, des enrichissements de mon information en utilisant des tables de référence, …
  • Mise à disposition : Aurais-je besoin de récupérer de l’information rapidement, avec des clefs de recherche complexe, sous différents formats, pour réaliser des impressions en masse, de l’éditique, …
  • Archivage : Ai-je des contraintes réglementaires à respecter, dois je garder des documents très longtemps, dois-je gérer la fin des cycles de vie de certains documents, …
  • Données de références : Faut il appliquer de nombreux référentiels formels, laisser les utilisateurs créer le leur, utiliser ceux déjà existants dans un ERP, …
  • Gouvernance : Quels informations vont être utilisées, dois je avoir une présence forte en terme de gouvernance, dois je accompagner les usages dans le temps afin de permettre la meilleure gestion des informations par les utilisateurs (et anticiper sur les dérives).

Cela permet déjà de dégrossir le terrain, d’évaluer un premier niveau d’attentes qui plus tard pourra correspondre à des spécifications fonctionnelles dans un cahier des charges. Cela donne une vue à un moment donné, et pourrait être enrichie en prenant du recul sur l’évolution des informations qui doivent être gérées.

Une vue selon le cycle de vie de l’information

Souvent la réponse au besoin est aussi ponctuelle que le besoin lui-même : Il me faut gérer ces documents précis => je mets en place l’outil permettant de le faire. Oui mais d’où vient le document, et où vat il après « l’émetteur du besoin ». Une des cause majeur d’inadéquation Logiciel-Besoin et justement parce que l’information vie. Pardonnez-moi cette comparaison, mais elle est comme nous, elle née et a des besoins particuliers tout au long de sa vie pour ensuite se « terminer » obligatoirement (ok le cas des infos qui restent une éternité sur des serveurs ne s’appliquent pas à nous, dommage !?).
Le graphe suivant, donne une bonne vue des évolutions des usages en fonction du cycle de vie de l’information. Lorsque l’information se crée elle est intensément manipulée, puis le devient de moins en moins dans le temps. La souplesse et la facilité d’utilisation doivent donc être tout au début du cycle de vie, puis la rigueur se mettre en place de plus en plus fortement pour ensuite considérer la destruction de l’information.

cycle-de-vie

Sur ce graphe j’ai fait apparaitre 3 grandes familles d’outils (il serait possible d’en rajouter) :

  • le collaboratif avec une forte fréquence de consultation et d’interactivité, les réseaux sociaux et les espaces projets sont considérés comme des espaces collaboratifs,
  • la Gestion Électronique de Document avec un peu plus de pérennité, d’intégrité, d’authentification, et une capacité à gérer de multiples informations, avec de multiples critères de classement,
  • L’archivage ayant une très forte dimension au niveau pérennité, classement, gestion de l’intégrité, peu d’accès, et la capacité de gérer des informations dans le temps (destruction, préservation technique, ..),

Du coup cela apporte un autre type de réflexion qui porterait l’analyse des besoins proche du cycle de vie de l’information. A savoir, mon besoin est il :

  • De favoriser des échanges, laisser libre la capacité à être créatif, à créer du savoir et du savoir faire, à le valoriser, …
  • De structurer un projet en laissant un maximum de souplesse à une équipe réduite mais très exigeante,
  • De maintenir des référentiels avec un maximum de rigueur, une plus faible dynamique, des contraintes conséquentes,
  • D’automatiser un processus à fort usage de document, en simplifiant les traitements et gardant dans le temps l’information,
  • De mettre à disposition de l’information engageante, avec une forte intégrité tout en s’affranchissant de contraintes techniques temporelles,

Peut être même le besoin touche à toutes les familles, ce qui ne serait d’ailleurs absolument pas surprenant, nous sommes aujourd’hui à un moment où la gestion de l’information est directement associée à la chaine de valeur, et donc de bout en bout.
Ce n’est pas pour rien que depuis quelques années, la majorité des éditeurs de solution « GED » ont investit énormément pour créer des plateformes ECM (Enterprise Content Management) de gestion de contenu, avec l’ensemble des briques fonctionnelles dont nous avons parlé au début de ce post.

J’espère que cela a pu dégrossir un peu le sujet du choix d’une solution de gestion de contenu. Dans tous les cas, un aspect qui est vraiment plus important que le choix de l’outil, concerne les fondamentaux et la gouvernance des informations qui seront à gérer.

La simple mise en place de l’outil, aussi sexy et adapté soit il, sera insuffisant aux usages qui en seront fait. Il y a bien sûr la conduite au changement, qui permettra la bonne prise en compte par les clients de la solution. Mais administrer, dans le temps, l’ensemble du système, voir une nouvelle offre de service de gestion d’information, sera le vrai challenge.

 

6 Responses to “Réseaux sociaux,GED, Archivage, Collaboratifs, Workflow, Email, ce sont tous les mêmes !

  • Hello, I can bounce on this very interesting article, especially for the concise and intelligible way of managing information company that is presented. Your article leads me to question, however, the reality of a business-focused approach rather than "live tool" as mentioned above (I limit myself below in case of electronic filing). If, indeed, the rational approach is that it focuses on the business requirements before implementing a solution, I repeatedly found that lead to this kind of project (electronic archiving so) is too often driven by CIOs as they are the ones that bring out the besoin.Par example, in the case of an audit will be asked the company to produce a particular document type (invoices, receipts, money orders , accounting statements, etc. …), the external auditor turned to accounting for example, which turns into … ISD natuerellement asking him to show the documents and data demandées.Si there is a loss this level is therefore ISD dating need, and often gets the budget if a GO is pronounced and this is the problem because the governance aspect is so often neglected. The question that arises is how to foster a sponsor and engage in a business problem that seems so far away? I'm obviously not the answer and only see from my experience but would be very interested to have some opinions …

  • Bonjour,

    Je me permet de rebondir sur cet article très intéressant, notamment pour l’approche synthétique et intelligible de la gestion de l’information en entreprise qui y est présentée.
    Votre article m’amène toutefois à me questionner sur la réalité d’une approche orientée métier plutôt que “direct outil” comme mentionné ci-dessus (je me limite ci-après au cas de l’archivage électronique).
    Si, en effet, l’approche rationnelle veut que l’on se penche sur les besoins métiers préalablement à l’implémentation d’une solution, j’ai constaté à plusieurs reprises que le lead de ce genre de projet (archivage électronique donc) est trop souvent porté par les DSI car ce sont elles qui font ressortir le besoin.Par exemple, dans le cas d’un audit, il sera demandé à l’entreprise de produire tel ou tel type de document (factures, justificatifs, mandats bancaires, états comptables, etc…), l’auditeur externe se tourne alors vers la comptabilité par exemple, qui se retourne…vers la DSI natuerellement en lui demandant de ressortir les documents et données demandées.Si il y a un manque à ce niveau là c’est donc la DSI qui remonte le besoin, et souvent obtient le budget si un GO est prononcé et c’est bien le problème car l’aspect gouvernance est alors fréquemment négligé. La question qui se pose alors est comment faire émerger un sponsor et intéresser les métiers à une problématique qui leur semble si lointaine ? Je n’ai évidemment pas la réponse et ne fait que constater par rapport à mon expérience mais serais très intéressé d’avoir quelques avis…

Trackbacks & Pings

%d bloggers like this: