CRM / SugarCRM – Partie 2

Voici donc la suite de mon billet sur le CRM et SugarCRM.

SugarCRM donc.

L’application permet, à la base, de gérer les données suivantes : Contact, Compte (regroupe plusieurs contacte), Affaire (associée à un Compte), Evènement (appel téléphonique, mail)…

Mais le modèle est particulièrement évolutif. Fondamentalement, le système permet de gérer… des données ayant des relations entre elles (on peut difficilement faire plus générique !). C’est pourquoi SugarCRM peut être utilisé pour des applications très variées, bien loin du modèle initial.

Autre sujet intéressant : comment brancher un site marchand sur le système de CRM ?

2 approches : on peut avoir les deux systèmes séparés, chacun ayant sa propre base de données.

Avantage : c’est propre, et les activités « back » ne viennent pas impacter ce qui se passe au niveau du Front.

Le problème est qu’il faut alors synchroniser les bases. Cette synchronisation va nécessiter un développement spécifique, qu’il faudra faire évoluer en permanence, pour des évolutions sur le front ou sur le back.

Autre solution : tout construire sur SugarCRM. Un client d’Ysance l’a fait, et ça marche très bien.

L’avantage est évident : un seul modèle de données, rien à synchroniser.

Problème ? Il faut être attentif à ce que les opérations du back n’impactent pas trop les performances du site. Cela va bien pour un site ayant un trafic « raisonnable ». C’est une bonne solution pour commencer, il sera toujours temps de faire évoluer le modèle.

CRM / SugarCRM – Partie 1

J’étais invité, l’autre jour, à une présentation de SugarCRM, organisée par Ysance (bravo Samuel).

Ysance connait très bien ce logiciel, pour l’avoir mis en œuvre dans de nombreux contextes.

CRM donc…

L’idée de base du CRM, c’est qu’il est plus rentable de cultiver les clients existants que de travailler à en ramener des nouveaux. Evidemment, il ne faut pas appliquer cette doctrine à la lettre : il est toujours bien d’aller chercher des nouveaux clients, mais celà nous rappelle qu’on peut travailler sur la base installée.

Travailler la base installée, cela veut nécessairement dire mieux travailler la relation avec ces clients.

La relation avec les clients, c’est :

  • La relation avant la vente, la relation durant la prospection donc ;
  • La relation pendant la vente ;
  • La relation après la vente, y compris le service après vente.

Une solution CRM, c’est une solution qui doit permettre de gérer l’ensemble des données et des processus liés à la relation entre l’entreprise et les clients.

SugarCRM est l’un des acteurs clé de ce marché, et le leader des solutions open-source.

SugarCRM commercialise différentes version de sa solution, et la version de base, déjà très complète, est gratuite. Les versions plus complètes sont payantes avec des prix somme toute raisonnables (de 275 $ à 450 $ par utilisateur et par ans).

Avoir une solution open source est important dans ce genre d’application. Par définition, cette application est au coeur du système d’information, et c’est donc important pour l’entreprise d’avoir la main sur le code source.

OpenSugar est une application écrite en PHP 5, utilisant une base de donnée (souvent MySQL, mais OpenSugar supporte d’autres bases).

Pour le e-commerce, le CRM est tout simplement vital !

La suite au prochain épisode !

Liberté d’expression sur Internet ? Quelles limites ?

L’affaire d’Eric m’inspire plusieurs réflexions.

Tout d’abord, Eric.

Eric est sympa, a un blog super, monte des services intéressants, et est attaqué pour une information qu’il n’a pas particulièrement choisie, sur un moteur d’agrégation de news, attaqué par apparemment quelqu’un qui a choisi de maximiser ses revenus comme ça… Bref, quelqu’un qui n’inspire pas une très grande sympatie ni beaucoup de respect.

Donc, oui, dans ce débat, je soutiens Eric, et l’idée d’une attaque sans même chercher à discuter me choque.

Maintenant, je ne peux m’empêcher de me poser des questions sur la liberté d’expression sur Internet, ses limites, et les responsabilités des uns et des autres.

Prenons un exemple simple : les propos racistes, ou les propos poussant à la haine, à la violence.

Si un bloggeur, ou n’importe quel site Internet, publie de tels informations, c’est bien entendue illégal, condamnable. Mais est-ce bien le cas ? Il me semble que ça serait autrement important que cette justice là soit bien plus respectée…

Maintenant, reprenons le cas d’un service qui agrège des informations de sites tiers. Si un tel site reprend des informations du type cité plus haut (racisme, …), sont ils responsables ? A mon sens, oui ! On ne peut pas se cacher derrière le paravent de la technique pour dire qu’on n’est pas responsable.

Avancer vite, ou sécuriser ?

Dans notre secteur, le e-commerce, une part importante des investissements est affectée au développement du système informatique : front-office et back office.

C’est un investissement important parce qu’il y a beaucoup de choses à développer : front, administration du front, gestion du processus de livraison, lien avec les systèmes des transporteurs, CRM, emailing, moteur de recherche, lien avec les plate-formes d’affiliation et moteurs de shopping, système de gestion du SAV, gestion du stock, …

Il n’existe pas de solution clé en main, couvrant tous les besoins. Il faut donc construire le système, à partir de différents composants, et réaliser les développements pour adapter ces composants au contexte de l’entreprise, et pour faire l’intégration entre les composants. De plus, l’activité e-commerce vient bien souvent compléter un système d’information déjà en partie construit : on arrive rarement en terrain vierge !

Comment font les entreprises pour développer leur système informatique ?

Plusieurs cas de figures bien entendu. Les grosses entreprises, ayant un gros système informatique, peuvent confier la mission de la mise en ligne d’un site marchand à l’équipe informatique. Dans ce scénario, on arrivera sans doute à un processus technique assez classique, avec cahier des charges, appel d’offre, …

Mais bien souvent, dans les petites structures, les moyens mis en œuvres seront beaucoup plus artisanaux : un développeur, et hop, le site est en ligne, avec bien souvent développement 100% maison.

Si le développeur est bon, le système peut marcher, et tenir quelques années : 2, 3, … 5 ?

C’est clairement le moyen le plus économique pour mettre en ligne un site marchand.

Le problème, c’est que tout l’édifice repose alors sur le savoir faire un peu magique d’un seul homme.

L’autre problème, c’est que l’entreprise aura une vision des développements très « particulière », puisque « la toute petite équipe technique » fonctionne sur un mode complètement informel, et que le développeur peut ainsi faire des modifications très très rapidement.

Plus tard, quand les revenus deviennent important, d’autres aspects surgissent : la fiabilité, la sécurité, …

Il faut alors changer de méthode, mettre en place de la redondance, à tous les niveaux (hard, humain). Tout cela est infiniment moins rapide qu’avant !

Ah là là, que la qualité coûte cher !

Abstraction or not abstraction

Le fondement même de la qualité, en matière de logiciel, passe par l’abstraction.

Si on veut écrire un logiciel apte à évoluer, on doit le concevoir sous la forme de modules.

Un module, c’est un ensemble de programmes, qui doivent résoudre un problème bien défini.

L’abstraction, c’est l’idée qu’on peut définir et programmer un module, sans aller voir dans les modules voisins : ceux avec qui les programmes discutes, a côté donc mais également en dessous.

Ainsi, quand on développe une application Windows par exemple, on a besoin de connaitre les API de Windows. Pas son fonctionnement intime.

Et bien actuellement, il me semble que cette idée est bien mise à mal. Quand on développe un service Internet, il est difficile de se positionner dans cette posture. Tout est incroyablement entre-mêlé.

Ainsi, pour mettre en ligne un service, qui va devoir supporter de grosses montée en charges, on doit tout prendre en compte, et avoir une culture qui mêle base de données, réseau, serveur Internet, …

C’est bien entendu une situation temporaire, qui met en avant la fragilité des architectures actuelles, et de la non maturité des solutions mises en oeuvre.

Ceci étant dit, il faut bien avancer et on doit faire avec !

L’après Google

Nous vivons sous l’aire Google.

C’est une domination absolue !

Google est LE moteur de recherche mondial pour Internet.

Et comme sur Internet, on trouve tout… à condition de savoir à quelle adresse, la fonction de recherche est devenue complètement centrale, au cœur de nos comportements d’Internautes.

Ainsi, pour un marchand, Google représente en général largement plus de la moitié du chiffre d’affaires.

Google a ensuite mis en place sa plate forme de publicité : Adwords.

Adwords est LA plate forme de publicité sur Internet. L’entreprise qui souhaite faire de la publicité achète des mots clés, et associe des annonces à ces mots clés, les annonces contenant un lien vers le site de l’entreprise.

Google se charge de pousser ces annonces, dans les « bonnes pages » : sur les pages d’affichage des résultats de la recherche, ou sur des pages intégrant le programme de publicité Google (Adsense).

Ces trois briques sont complètement imbriquées. Le moteur de recherche est la racine de tout. Adwords et Adsense utilisent les connaissances du moteur de recherche pour proposer des publicités extrêmement contextualisées.

Mais vous savez sans doute tout ça. J’en reparle juste pour « reposer le décor ».

Cette domination absolue ne peut pas durer éternellement.

D’abord, elle est trop dangereuse. Sur Internet comme dans n’importe quelle industrie, il n’est pas sain qu’un seul acteur ait une domination aussi forte. On s’en rend compte par exemple lors des censures liées à la Chine et au Tibet.

Et puis, le contexte évolue. C’est la vie des entreprises.

Alors, quels sont les évolutions, les changements qui peuvent déstabiliser Google, et permettre l’émergence de solutions alternatives ?

On peut tout d’abord imaginer que les lois anti-trust interviennent, comme elles sont par exemple intervenues, dans les années 80, pour démanteler AT&T.

Mais comment découper Google ?

L’activité de recherche, sans la fonction publicité, ne rapporte rien…

On pourrait imaginer imposer ce découpage (moteur de recherche / moteur de publicité) avec des API publiques et des contrats entre les entités. L’avantage de cette découpe est qu’elle permettrait, théoriquement, l’émergence d’autres moteurs de publicités, utilisant les bases d’index du moteur de recherche de Google.

L’autre évènement, qui pourrait modifier la donne, vient de l’évolution constante du Web.

Le modèle « page HTML avec des liens » sur lequel est entièrement bâti Google commence à vieillir.

Le Web devient interactif, richmedia.

Aujourd’hui, la solution passe par du déclaratif. On met des applications richmedia en ligne, et en parallèle, si on veut avoir un minimum de référencement sur Google, on met en ligne des données adaptées à Google.

C’est nécessairement une solution de transition, un plâtre provisoire.

Des solutions mieux adaptées aux contenus richmedia et aux applications en lignes vont nécessairement émerger.

Google pourra-t-il s’adapter à ces nouveaux modèles, en rupture avec son « Page Rank » ? Difficile pour Google, quand tout le business model est basé dessus…

D’autres acteurs pourront- ils créer des solutions crédibles ? Quels sont les investissements nécessaires pour atteindre la masse critique minimum ? L’intelligence de Google, à ses débuts, est d’avoir pris en compte, dès le début, l’ensemble de la problématique : pas simplement l’algorithme de recherche, mais également le problème lié au volume.

Les joies et les peines de la livraison

J’étais tout à l’heure avec Romain, d’Ysance.

Romain me parlait de ses déboires liés à la livraison. Voici son histoire donc.

Romain a acheté un produit sur un site en ligne.

Sur le site marchand, il n’y a pas de champ pour expliquer comment bien effectuer la livraison, et en particulier, pas de champ pour donner les différents codes d’accès, numéro de bâtiment, …

Au moment de la livraison, que croyez vous qu’il arriva ? Le transporteur est bien passé, n’a pas trouvé les infos pour effectuer la livraison, et est reparti, sans se poser plus de question.

Devise Shadok : Plus ça rate, plus ça risque de réussir...

Romain fini par récupérer son produit.

Malheur : le produit ne marche pas. Romain contacte le site, et rentre alors dans un processus de réexpédition vers le marchand.

Là, le transporteur lui demande d’être chez lui une demi journée !

En fait, on est surement en face de transporteurs et de marchands qui pensent que les clients ne travaillent pas ?

En fait, beaucoup des problèmes viennent des objectifs des contrats entre les marchands et les transporteurs. Si les objectifs ne sont pas bon, on arrive à ce genre de résultat…

Le pire, c’est que la plupart des clients sont prêt à payer plus cher pour un meilleur service.

Concevoir des interfaces riches : nouveau métier ou déjà vu ?

Discussion enflammée lors du buffet, après le lancement de AIR et de Flex 3.

La thèse de mes interlocuteurs : rien de neuf sous le soleil. Concevoir une application riche, c’est du déjà vu. On faisait déjà ça au 18ème siècle (sic) !

Mes interlocuteurs : un ergonome et un consultant.

Je ne partage pas du tout leur point de vue.

Je pense qu’au contraire, la conception d’un service web, et encore plus d’un service web riche, c’est un vrai nouveau métier.

Je ne crois pas qu’on peut concevoir l’intelligence, l’ergonomie, la fluidité, la beauté d’un service comme on concevait un meuble.

Je pense que c’est fondamentalement des métiers différents, qui demandent des cultures différentes, des outils différents…