Crm & ged (1/2)

Un conseiller bancaire m'a récemment donné un exemple des avantages à disposer d'une GED. La signature des clients de cette banque est numérisée et rattachée à la fiche des clients. Cela permet à un jeune conseiller de vérifier les documents signés et remis par un client au guichet sans avoir à lui demander une pièce d'identité. Un client fidèle (Senior, en l'occurrence) n'apprécie pas du tout, en effet, qu'on ne le "reconnaisse pas".

J'ai déjà réalisé l'intégration d'outils de GED au cours de projets CRM. En consultation, c'était en priorité pour permettre à l'utilisateur d'accéder à l'ensemble des documents rattachés à un client : l'application CRM offre alors une fenêtre vers la GED, à la manière d'un portail. En création, la GED est en général alimentée automatiquement des documents générés via l'application CRM (courrier, fax, email).

1. Interface CRM - Editique & Interface CRM - GED

Dans le cadre d'un projet CRM, il s'agit de déterminer quelle application (et quel espace de stockage avec son niveau de service approprié) est chargée de l'édition, de la sauvegarde et du partage des documents. Lorsque la solution CRM propose uniquement de sauvegarder les documents dans sa propre architecture (SGBD ou File System), elle entre alors en concurrence avec les solutions de GED parfois déjà existantes dans le SI. Il en est de même pour les solutions CRM incapables de transférer l'édition à un outil spécialisé qui saura gérer différents formats (email, courrier, fax, sms, publication ...) et ajouter rapidement de nouveaux canaux de communication.

La présence des API dans les solutions CRM apportent des solutions. CoherisCRM et E-Deal disposent par exemple d'une API (web services) capable de mettre en oeuvre une interface d'échange de document avec toute application d'éditique et de GED. La solution CRM génère un objet "Document" et le transfère à l'application voulue. Cette dernière prend en charge la suite du processus (édition, expédition, sauvegarde, ...). Elle peut aussi retourner au CRM un identifiant unique et un chemin d'accès en GED.

2. Wokflow, ouverture et intégration.

Le récent article de Laurent Hénault sur Neteco.com va plus loin. Il insiste sur le rapprochement nécessaire de la conception des processus (BPM) avec la GED pour accroître la productivité via la collaboration (partage, workflow, droits d'accès), la décentralisation et la traçabilité.

Les solutions de CRM permettent de formaliser et d'automatiser des échanges d'informations entre différents participants, ce que l'on peut appeler des workflows. En ce qui concerne le cycle de vie du document, le besoin peut s'enrichir rapidement : gestion des validations, suivi des versions, suivi de l'état du document, etc. Plusieurs solutions CRM apportent une réponse spécifique à ce besoin, notamment les solutions dédiés au marketing direct qui intègrent souvent des circuits de validation.

Ce n'est pas forcément gênant puisque chaque métier dispose souvent de ses processus et des outils propres. En revanche, le risque est de construire des environnements verticaux fermés (silos) alors qu'il faudrait par exemple que toute fiche client d'une application CRM XXX puisse afficher les sollications marketing envoyées via l'application YYY. Autre exemple : il est de plus en plus nécessaire de pouvoir faire intervenir des partenaires ou des interlocuteurs en dehors de la société dans la rédaction/validation d'un document et donc d'ouvrir le processus et le worfkflow documentaire à Internet.

Maintenant que les services sont de plus en plus sous-traités ou assemblés pour construire une offre globale, les processus de vente font intervenir de nombreux interlocuteurs et de nombreuses applications (prêt immobilier, souscription à un abonnement électrique ...). Tandis que les données clients sont encore souvent échangées et dupliquées, la GED a naturellement tendance à se placer au centre d'un réseau d'applications et à tenter de prendre en charge les workflows spécifiques.

En 2006/2007, j'ai mis en place, dans deux projets CRM, un droit d'accès sur le traitement d'une demande client (et ses documents associés) calculé en fonction de l'origine et de l'état de cette demande (information disponible uniquement dans le CRM). J'ai le sentiment que les futurs systèmes d'information regroupant CRM, Editique et GED devront permettre une forte intégration pour proposer aux utilisateurs un processus continu de traitement des demandes avec une administration souple des droits d'accès (lecteur, co-auteur, valideur ...) en fonction de leurs profils et du statut du processus en cours (différent du statut du document bien que souvent identique).

Par exemple, un processus de vente de prêt immobilier généré par un courtier peut justifier l'intervention de son partenaire banquier dans la rédaction d'une offre difficile. A l'initialisation du processus CRM, le cycle de vie du document commence à partir d'un document modèle que le courtier personnalise. Le courtier génère ensuite une tâche de validation dans l'agenda CRM du partenaire. Le partenaire consulte l'offre standard et la modifie (ce qui modifie le statut du document). Une nouvelle tâche est automatiquement affectée au service financier qui dispose désormais d'un droit de valideur sur le document (mais pas co-auteur). Le document validé (ce qui modifie le statut du processus), le partenaire financier perd son droit de co-auteur : son droit est converti en lecteur. Etc.

Demain, les projets CRM chercheront sûrement une intégration riche avec les outils de GED (à l'exemple de l'Editique; exemple : StreamServe, Bdoc ) pour apporter de nouvelles fonctionnalités...