Justement, quelles sont ces applications analytiques que proposent les éditeurs de la business intelligence ?
De ce côté-là, la vraie question est de savoir si en terme de CRM analytique, celui-ci se branche ou non sur le CRM opérationnel. Certains traitent ou non la connexion avec d'autres acteurs. Prenons d'abord le leader, Business Objects à travers sa nouvelle offre d'applications analytiques. Ces produits traitent complètement et de façon détaillée la partie analytique, mais n'offrent pas de pont naturel vers le front-office. En revanche, Business Objects dispose de connexions vers des acteurs comme Siebel. Informatica aussi commence à se positionner avec un début d'offre d'applications analytiques, mais ce n'est pas son coeur de métier. En revanche, Informatica montre une bonne stratégie à travers l'ETL. En règle générale, tous les intervenants essaient de déborder de leur positionnement initial. Chacun vient de sa niche et essaie de s'étendre.

MicroStrategy et Brio, par exemple, sont typiques de la tendance à coloniser le back-office pour remonter ensuite vers le front-office. Mais ils n'en sont pas tous au même niveau. Oracle propose la totale, Business Objects s'approche, tandis que Brio et Cognos en sont encore loin. Pour revenir à MicroStrategy, sa suite de CRM analytique comprend tous les outils d'analyse et de reporting. Avec elle, soit l'entreprise développe ses tableaux de bord à la main et s'appuie sur son intégrateur préféré pour les définir plus précisément, soit elle prend l'offre dans laquelle elle trouve 1 000 tableaux de bord prêts à l'emploi. Ce dernier point comporte un avantage en terme de réduction des développements. Et quand les utilisateurs ne sont pas mûrs pour paramétrer des indicateurs, l'entreprise profite de toute une richesse de tableaux de bord à l'intérieur d'une offre packagée.

Pour de l'analyse et du reporting plus poussés, faut-il une approche best-of-breed ou plutôt intégrée, si cela pose problème d'agréger des solutions ?
Il faut trancher et cela dépend de la sophistication de ce que l'entreprise désire mettre en place. Si elle recherche du reporting basique, elle peut tout à fait opter une solution CRM intégrée. Mais si elle veut aller plus loin, il lui faudra passer à des outils plus évolués. Dans le cas de Siebel, celui-ci ne pratique pas l'analyse mais la propose par exemple par le biais d'Hyperion. En attendant, si l'intégration n'est pas serrée, cela peut passer par le fait de dupliquer les bases au préalable de la consolidation de l'entrepôt de données.

A l'inverse, si l'entreprise a des besoins classiques en terme de CRM opérationnel, elle peut choisir Oracle chez qui la partie front-office de la gestion de la relation client est moins fouillée que Siebel. Il faut d'abord regarder les budgets en terme de licences, d'intégration et de maintenance, et après cela dépend de là où se situe le plus fort besoin. .

Nous n'avons pas parlé d'IBM, qui pourtant semble avoir un certain nombre d'outils au catalogue... ?
IBM se positionne essentiellement comme revendeur d'un certain nombre de solutions. Nous n'avons pas non plus parlé de NCR, qui propose à la fois son datawarehouse Teradata et une suite de CRM front-office. Dans toute la liste des acteurs, si nous résumons, nous retrouvons ceux qui viennent de la business intelligence, ceux qui éditent des ERP et ceux qui sont positionnés sur le front-office. Soit la spécificité de l'entreprise veut qu'elle insiste sur certaines fonctions du CRM, soit elle préfère des fonctions classiques côté front-office mais plus sophistiquées en back-office.

Tous ces éditeurs proposent de l'analyse avec des outils, mais leur choix est toujours assez complexe. Finalement, nous avons parlé des processus, de la catégorisation des solutions et de leur choix, mais pas de certains aspects fondamentaux des projets CRM qui sont des facteurs de risques assez critiques. Or, ce sont des aspects que l'on n'a pas l'habitude de regarder, et pourtant ce sont ceux-là qui déterminent si le projet va réussir ou rater.

Quels sont ces fameux facteurs de risques ?
Le projet CRM produit essentiellement un impact fort sur l'organisation de l'entreprise et sur ses processus de travail. Dans une organisation, on retrouve aussi bien une direction commerciale, une direction marketing, une direction pour le support client... et chacun a sa petite vision de son client avec sa façon de le définir et ainsi de suite. A partir du moment où le CRM entre en ligne de compte, le motto devient "le client au centre de l'entreprise". La vision est la même pour tous, chacun doit accepter de voir le client sous la même grille.

Mais aussi, il faut que les différents départements acceptent de partager leurs informations. Or, si vous demandez à votre vendeur sur le terrain de partager ses informations, il refuse tout net car ce sont ses clients à lui. En fait, plus que sur les critères de choix, les projets échouent non à cause de la technique mais en raison des problèmes d'organisation. Et ceci, parce que l'entreprise ne veut pas changer autour d'une nouvelle philosophie de fonctionnement. Il faudrait pour cela abandonner certaines luttes de territoire...

Ensuite, il faut parler des processus de travail. Le marketing travaille à sa façon, le commercial aussi, et derrière nous retrouvons l'informatique. Avec la mise en place des processus de CRM, le travail va devoir s'effectuer de façon différente. Peut-être que dans l'acquisition de l'information client, puis son passage à un autre département, le processus traditionnel devra être modifié. L'impact sur le travail au jour le jour est ce qu'il y a de plus important, et c'est là que ça coince.

Pour en revenir au choix des solutions, en existe-t-il certaines qui sont plus faciles que d'autres à accepter dans l'organisation ?
Nous pouvons en effet être amenés à des raisonnements selon lesquels certains outils demandent des remises en cause profondes de l'organisation. Par exemple, pour Siebel il faut procéder à une modélisation des processus de l'entreprise sur ce que permet la solution. Et là, c'est lourd et on ne rigole pas. L'impact est plus important que ce que l'on croit.

D'autres outils seront plus légers, comme Selligent qui demande un travail moins en profondeur sur ces aspects car il rentre moins en profondeur dans l'organisation. Avec cette solution, peut-être que certaines pratiques resteront aussi plus artisanales et moins automatisées. Et cela provoque des impacts très importants sur la mise en oeuvre.

Enfin, certains clients nous rapportent que tel ou tel outil est un "outil à l'américaine". C'est par exemple le cas de Siebel, qui propose une vision de l'entreprise à l'américaine et s'adapte plus à des multinationales. Bien sûr, les critères techniques sont importants. Mais aussi bien sur les parties du front-office que sur les autres parties du back-office, il faut aborder tout ce qui a trait à la conduite du changement et auquel on ne pense pas toujours.

Le développement spécifique peut-il être parfois une alternative pour répondre à un besoin précis ?
Sur ce point, il faut aussi penser en terme de budgets, c'est à dire licences, développements/intégration, et maintenance. En appliquant un barême, si le choix se porte sur du tout spécifique, les licences sont à zéro, les développements et l'intégration à un, et en maintenance cela devient très lourd. S'il faut accepter une nouvelle version et faire évoluer le système au dessus de la base Oracle, cela ne va plus du tout. Le grand avantage de départ se paie en budget de maintenance. Et en plus, l'entreprise n'a que ce dont elle a besoin sans profiter de toute l'expertise métier packagée. Dans Siebel figure l'expertise de centaines de personnes. L'entreprise en voit dix fois trop, mais lorsque nous l'installons nous cachons certaines fonctions. Au cours du temps, une solution spécifique devient donc plus pauvre et moins fonctionnelle.

De l'autre côté, quand le choix initial se porte sur du progiciel, le budget de licence et celui d'intégration équivalent en totalité à ce qu'il faut pour du développement spécifique. Mais en maintenance, l'entreprise ne paie que 15 % du prix de la licence chaque année. Pour les évolutions, certaines sont parfois gratuitement comprises dans la maintenance, et donc il faut choisir des éditeurs qui soient pérennes. Sinon, au début le choix se porte sur un certain nombre de modules, puis l'entreprise achète un module de plus et paramètre les évolutions dans ses composantes initiales. Avec un progiciel, on sait où l'on va.

Notre discours consiste donc à dire : "Jamais de spécifique, car c'est un choix très dangereux". Cela concerne aussi les clients qui veulent faire du spécifique sur le progiciel et le tordent. Puis, le progiciel évolue et il faut refaire tout le spécifique. Certains ont adopté cette tendance et s'en mordent les doigts. Après avoir essayé de le maintenir, ils jettent la partie spécifique et reviennent à la version pure et dure. Un logiciel suppose aussi bien des avantages que des contraintes, et il faut le prendre tel qu'il est. Cela peut forcer à adapter beaucoup l'organisation, et nous en revenons au problème précédent.

Retourner à la première partie de l'entretien