Journal du Net > Solutions > DSI >  > DSI > Analyses > Le référentiel VCOR
Analyse
 
04/05/2007

Un référentiel qui s'adapte aux projets CRM

De l'écoute du besoin marché au suivi après-vente, le modèle Value Chain Operations Reference permet d'accélerer la structuration des processus de la relation client.
  Envoyer Imprimer  

 
En savoir plus
 
 

Jean-François Pirus
 

La première version du modèle VCOR (Value Chain Operations Reference) a été développée à la suite d'une série de réunions entre la fin des années 2003 et le début des années 2004. Les participants à ces réunions étaient, pour la plupart, des experts en processus métier.

Beaucoup d'entre eux travaillaient pour de grandes entreprises allant des sociétés de conseil à des associations loi 1901 sur des domaines spécifiques, en passant par les universités.

Au cours de l'automne 2004 quelques uns de ces participants formèrent une association à but non lucratif qui deviendra, par la suite, le Value Chain Group Inc. Par la suite, au début de l'année 2005, un conseil d'administration a été désigné pour définir les premières règles de l'association. Elle fut alors officiellement lancée en tant qu'organisation mondiale.

Vue d'ensemble sur le référentiel

Les processus du référentiel VCOR sont structurés en 3 ensembles :
» GOVERN : pilotage
» PLAN : planification
» EXECUTE : processus opérationnels

La dimension Govern couvrira à la fois le pilotage stratégique au travers de celui de la chaîne de valeur ("govern value chain" et le pilotage opérationnel, décliné par processus.

La dimension Plan se décline elle aussi au niveau processus selon les 4 mêmes étapes partant du recueil des besoins de ressources pour aboutir à l’élaboration de la prévision.

Les macro processus couverts par la dimension Execute sont au nombre de neuf. En amont de la chaîne de valeur, on trouve 3 processus de Développement : l’analyse des besoins du marché (Market), les travaux de Recherche et Développement permettant de déboucher sur une offre adaptée (Research) et le développement de l’offre de produits/services (Develop).

Le positionnement (notamment tarifaire) de l’offre dans une perspective de gestion des marques n’est pas oublié (Brand).

La partie Gestion commerciale sépare l’avant-vente (sous le terme trompeur de "Sell") qui inclut la contractualisation de la relation client, la gestion commerciale (Fulfill) qui couvre le traitement des commandes jusqu’au règlement des factures, la production (Build) et la relation fournisseur (Acquire). Enfin le support après-vente traitera notamment de la gestion des incidents et des retours mais aussi de l’organisation de sessions de formation en réponse à une mauvaise maîtrise du produit vendu.

Si l’on intègre la planification, l’ensemble Plan, Acquire, Build, Fulfill et Support n’est pas sans rappeler les 5 macro-processus du référentiel Scor (Plan, Source, Make, Deliver et Return).

Chacun de ces macro-processus est subdivisé en un ensemble structuré de processus. En parallèle de cette décomposition, les 3 processus de développement sont déclinés suivant le niveau d’adaptation de la réponse faite au besoin client :
» design to market,
» co-design,
» design to specs,
pour aboutir, par exemple à “research design to market”.

De même, les 3 processus de relation fournisseur sont également déclinés :
» "to stock" : commandes de produits standards poussées (push) par les prévisions de vente ;
» "to order" : commandes tirées (pull) par les commandes fermes des clients ;
» "to engineer" : commandes tirées requérant de la conception sur mesure.

Enfin, les 3 processus de relation client sont déclinés en 4 sous-ensembles suivant une matrice à deux dimensions (produit existant / nouveau produit d’un côté, marché existant / nouveau marché de l’autre) pour aboutir par exemple au processus de commercialisation d’un produit existant sur un nouveau marché.

Au total, 26 processus se décomposent en un total de 191 sous-processus.

 

Ces processus sont reliés entre eux via 4 types d’entrées-sorties :
» des flux financiers, décomposés en 5 sous-ensembles : flux trésorerie, crédit, client, fournisseur et flux budget ;
» des flux matériels, décomposés en matières premières, pièces détachées, composants et produits ;
» des flux ressources, décomposées en actifs, ressources humaines et informatiques ;
» et des flux informations, décomposées en documents, transactions (entrée- sorties avec impact contractuel) et décisions (règles de gestion notamment).

 

Une approche normative des vues pilotage et planification

Les 9 macro-processus ont chacun leur processus "Plan" et "Govern" propres : plan market, govern develop…

Pour chaque macro-processus, dix dimensions sont potentiellement à couvrir :
» les règles de gestion (« rule »),
» la finance,
» les actifs (matériels),
» l’information (actifs immatériels),
» les ressources humaines (« personnel »),
» la performance (intrinsèque du processus),
» le réseau et partenaires (« network »),
» la gestion du changement,
» la conformité réglementaire (« compliance »),
» et le cycle de vie.

Cette approche systématique et normative signifie que, pour chaque processus identifié dans la cartographie, la mise en œuvre d’un système de pilotage du processus s’attachera à balayer l’ensemble de ces dimensions pour identifier des enjeux de pilotage (risques, potentiel d’amélioration,…), définir les indicateurs appropriés et les structurer dans des tableaux de bord.

Ces axes de pilotage (souvent et improprement appelés "processus"), correspondront à un ensemble d’indicateurs. Ceux-ci concourent à l’atteinte de 7 objectifs de management :
» fiabilité,
» rapidité,
» adaptabilit,é
» maîtrise des coûts,
» optimisation des ressources,
» innovation,
» et orientation client.

Qui plus est, l’imbrication des vues Pilotage, Planification et Processus au sein du référentiel permet de comprendre les interactions entre indicateur de pilotage et processus métier : utilisation par un processus de données issues du pilotage stratégiques, mise à jour par le processus d’indicateurs utilisés pour le pilotage.

 

Un référentiel pour quel usage ?

Comme tout référentiel, VCOR ne doit pas être vu comme une solution toute faite mais au contraire comme un cadre de référence qui permet de gagner du temps en ne repartant pas de la feuille blanche.

Ce référentiel est particulièrement adapté quand il s’agira de lister et structurer les processus de la relation client, d’évaluer ou de concevoir un système de pilotage de ces processus ou de structurer la carte fonctionnelle cible d’un système d’information de type CRM.

Côte processus, le référentiel couvrira sans difficulté les besoins de cartographie déconnectée de l’organisation, étape fondamentale et trop souvent négligée qui doit chapeauter et précéder la déclinaison des processus sur une organisation particulière.

En matière de pilotage, l’approche normative retenue par VCOR fournit une grille d’analyse normalisée de l’ensemble des processus et permet une analyse transversale d’une dimension donnée (suivi de la conformité tous processus confondus par exemple). Par ailleurs, le fait que le référentiel ne se contente pas de proposer des indicateurs mais précise les étapes qui doivent permettre de les construire est un apport précieux au plan opérationnel.

Enfin, en terme de SI, et à quelques aménagement près (reclassement des parties Achats et Contrat notamment dans les zones adéquates du SI cible), il permettra de structurer la vue urbanisée d’un système de CRM, en évitant d’être influencé par le périmètre applicatif des principales solutions du marché.

 

 
En savoir plus
 
 

Jean-François Pirus
 

A l’usage, le référentiel VCOR s’avère globalement pertinent, y compris dans des contextes de vente de prestations ou de fourniture de services publics. Seul le processus de fabrication, ciblé « produit » et « industrie » aura besoin d’être largement revisité dès lors que l’on ne traite pas de production industrielle. Mais quoi de plus naturel que de devoir adapter son processus « cœur de métier » ?

On regrettera simplement que ce référentiel ne soit pas francisé ni disponible au sein d’un outil de modélisation standard du marché, l’ergonomie de l’interface en ligne ne facilitant pas la reprise des données.

Gageons que s’il rencontre le même succès que SCOR ou ITIL, cela ne devrait pas tarder.

Jean-François PIRUS, BPMS.info


JDN Solutions Envoyer Imprimer Haut de page

Sondage

Les bases de données open source sont-elles désormais à la hauteur pour les systèmes d'entreprise ?

Tous les sondages