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.      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.   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.   Incoming search terms:archivage email (1)archiver contenu collaboratif (1)contraintes réglementaires réseaux sociaux (1)ged cahier des charges (1)gestion électronique de document (1)Partager : Digg this post Recommend on Facebook Share on FriendFeed Buzz it up Share on Linkedin Share on netvibes Share with Stumblers Tweet about it Buzz it up Print for later Bookmark in Browser Tell a friend Voir aussi :