Conforter le client dans ses choix

Lorsque le client manifeste son désir de passer commande, l’entreprise a intérêt à continuer à le rassurer afin de lui montrer qu’il fait le bon choix. Cela facilitera la progression dans la construction de la relation.

Rassurer tout au long de la commande

Il est très important que le client sache qu’une fois entré dans le « bon de commande », il a la possibilité d’en ressortir à n’importe quel moment, avec autant de facilité que s’il voulait quitter une autre partie du site.

Avant de demander au client de payer, il est préférable de lui rappeler les caractéristiques de l’offre (prix, quantité, date de livraison…), afin de lui montrer implicitement que l’entreprise ne cherche pas à le « rouler », et tout simplement pour éviter les erreurs.

Au moment où le client doit saisir ses coordonnées, notamment son numéro de carte bancaire, il convient de rappeler que la transaction est sécurisée.

Ensuite, il ne faut pas oublier de présenter un récapitulatif de la commande. Un site comme Amazon.com communique, en plus de cela, un numéro de référence, ainsi qu’un numéro de téléphone si le client souhaite avoir un contact vocal. Il n’en aura vraisemblablement pas besoin.

Tenir le client informé après sa commande

Après avoir enregistré une commande, l’entreprise est naturellement contente. Le client, quant à lui, ne l’est pas encore : il ne profite toujours pas du bien désiré. Le temps lui semblera d’autant plus long qu’il aura peur d’avoir été oublié.

En l’informant quelques temps plus tard que le bien a été expédié, l’entreprise lui rappelle qu’elle pense à lui, à ses préoccupations et, en fin de compte, autant à sa satisfaction qu’à son argent.

Respecter ses engagements

Évidemment, cela ne sert strictement à rien de rassurer le client pour ensuite le décevoir. Il serait alors impossible de construire une relation.

Le bien commandé doit arriver intact au domicile du client et dans les délais impartis. Il peut arriver que l’entreprise rencontre un problème. Mais cela doit rester tout à fait exceptionnel et le client doit être dédommagé d’une façon ou d’une autre si l’on ne veut pas risquer de le perdre, et d’en perdre d’autres, par effet de bouche-à-oreille.

Le cybercommerce est un travail de pros!

Net-économie

On croit souvent que la net-économie, grâce à l’internet et au Web, est avant tout pour les entreprises l’informatisation des échanges (B to B, B to C, ou encore B to E, ou B to A), après l’informatisation de la gestion et celle de la production. Les exposés de la matinée ont montré clairement que ce schéma linéaire est loin de la réalité. L’informatisation des relations avec les clients et avec les fournisseurs, ou encore avec les employés ou les administrations, suppose des changements profonds qui concernent l’organisation dans ses différentes dimensions, et au-delà la stratégie et la culture des entreprises.

Méthodes agiles : le renouveau des relations client / fournisseur dans l’ingénierie

Replacer le donneur d’ordre au coeur du cycle de développement d’un projet informatique, en instaurant des relations de collaboration avec le fournisseur. C’est, dans la théorie, l’un des principaux défis que doivent relever les méthodes agiles. Un concept de gestion de projet – pas uniquement informatique d’ailleurs – dont le but est de trancher avec le cycle classique de l’ingénierie logicielle, en instaurant notamment, par le biais de courtes étapes – on parle d’itération -, une relation de confiance entre prestataires et clients.

Si le principe d’agilité repose sur un manifeste très théorique élaboré dans les années 90, son application dans le cadre de projet logiciel n’en demeure pas moins très concret. Les méthodes agiles reprennent ainsi ce manifeste, mettant l’accent notamment sur la qualité du code, la planification et le pilotage du projet.

Le principe d’agilité consiste ainsi à faire évoluer le développement d’un produit en découpant son élaboration en de courtes étapes, qui débouchent, chacune inévitablement sur un livrable fonctionnel. Ces courtes « itérations », dont la durée est fixe, autorisent alors le client à intervenir en cours de projet pour redéfinir ses besoins en matière de fonctionnalités ou les priorités du projet. « L’agilité réside alors dans la façon de s’adapter au contexte et aux besoins des clients », souligne Mariano Boni, directeur technique de Dreamsoft-Solucom group, un cabinet de consultants expert en méthode agile. Le tout est « cimenté par une gestion des rôles –  définis en amont – , de la communication et des échanges entre les membres des équipes » côté fournisseur. Mais également côté client qui doit alors ré-évaluer, avec l’équipe en place, ses besoins à chaque itération. Ces principes sont  définis dans une méthode, qui décrit les mécanismes de déroulement d’un projet.

Parmi ces méthodes, on compte notamment Scrum et XP (Extreme Programming), qui se distinguent clairement. Toutes deux commencent à gagner en crédibilité sur le marché (voir l’encadré Les méthodes agiles : panorama et répartition).

Une pression du changement prise en compte

Principal résultat recherché : la réduction des cycles de développements et de déploiement. Du fait de la fréquence des interactions, le livrable est généralement conforme aux besoins du client et les objectifs métiers sont abordés dès le départ du projet. Autant de bénéfices qui tranchent avec le modèle classique, commente Oana Juncu, directeur de projet chez Sfeir, SSII française spécialisée dans les développements Web, qui explique qu’ « aujourd’hui, les projets sont davantage soumis à la pression du changement, rendant difficile la mise en place de lourdes procédures de cahier des charges à rallonge, d’intervenants extérieurs multiples, sans compter les inévitables oublis. Le produit développé est ainsi réglé par des itérations fixes, avec des périmètres définis. Et, à la fin de chaque itération, le produit, soumis alors à des points de contrôle, doit fonctionner. »

La modèle classique dit en cascade agit sur de longs processus, impliquant alors une incapacité de faire évoluer les besoins. « Alors qu’inévitablement, on sait que sur un long projet, les besoins fonctionnels du client vont murir, souligne Oana Juncu. Avec un modèle classique, on entre dans un protocole de qualification qui pénalise le projet. Est-ce dans le périmètre ou pas [NDLR, défini en amont dans le contrat] ? » Le modèle en cascade, utilisé en grande majorité dans les projets informatiques, consiste à compartimenter le projet en phases distinctes sur le principe du non-retour. Lorsque une phase est achevée, son résultat sert de point d’entrée à la phase suivante.

Partager les risques dans la collaboration

« Dans le monde cruel de l’informatique, les contrats de développement logiciel ont souvent pour les clients un objectif supplémentaire de transférer le plus possible les risques sur un fournisseur qui « sait faire ». En s’engageant sur un périmètre fonctionnel et un montant, le fournisseur prend à son compte la complexité des projets informatiques », souligne David Gageot, dans un livre blanc de la société Valtech Technology, SSII spécialisée notamment dans le conseil autour des méthodes agiles.

En intégrant le client au coeur des processus de développement, le principe de l’agilité bouleverse la relation client/fournisseur. Et répartit les risques dans les deux camps. Un point que détaille notamment Pierre Pezziardi sur un blog de la société Octo Technology, cabinet d’architectes en systèmes d’information. « Le processus en cascade crée structurellement du risque qu’il refoule, tandis que l’incrémental intègre ce risque en le mitigeant par des cycles de livraison rapides ».

Facturer à l’étape

Conséquence directe, le calcul du coût du projet doit prendre en compte ces évolutions. Et c’est souvent ce point qui d’ailleurs est présenté comme un des freins principaux à l’acceptation par les entreprises du principe d’agilité dans un projet de développement. « Le contrôle des coûts est entre les mains des clients, car il peut arrêter à tout moment le cheminements des itérations », résume Oana Juncu.
Car les itérations pèse sur le budget du projet, comme l’explique Mariono Boni. « Multiplier les mises en production coûte davantage que de se limiter à un seule et unique déploiement de grande ampleur. Reste que le gain se situe dans l’accélération des développements, et dans un time-to-market beaucoup plus rapide », insiste-t-il. Un coût supplémentaire certes, mais compensé par un développement qui ne manque pas (ou rarement) son but. Un discours qui reste difficile à faire passer en temps de crise.

Les méthodes agiles : panorama et répartition

Si l’éventail des méthodes agiles commence à s’étoffer, deux d’entre elles ont la côte, Scrum et eXtreme Programming (XP), résume Mariono Boni, directeur technique de Dreamsoft. Scrum (mélée en français) se distinguant d’une large tête sur le marché en terme d’adoption. Selon une étude réalisée par VersionOne, éditeur d’outil pour les méthodes agiles, 49 % des quelque 3 000 répondants – des entreprises envisageant ou ayant déjà adopté le principe d’agilité – suivent Scrum. 22 % d’entre elles ont recours à une méthode hybride, mélant XP et Scrum. Et, enfin, les 29% restant s’en remettent aux autres méthodes du marché. Si Mariono Boni explique qu’on ne peut pas mettre de l’agilité dans tous les projets, il apparaît également que chaque méthode ne répond pas à tous les scenarii. Des entreprises conjuguent ainsi des principes tirés de différentes méthodes, pour coller au plus prêt à leurs besoins. Cette même étude met en exergue cette cohabitation : quelque 5,3 % des répondants conjuguant plusieurs méthodes (sans autre précision). D’autres (3,7 %) utilisent eux les méthodes agiles sans en connaître l’étiquette.

Une approche holistique s’impose

La SOA, approche architecturale d’une problématique plus vaste, n’est qu’une partie de la réponse, et ne peut donc être abordée seule. Un projet SOA doit s’inscrire dans la stratégie que l’entreprise soutient grâce à une architecture claire, souple et réactive. La SOA est donc un moyen, et non une fin en soi. Un projet SOA géré comme un projet informatique banal est voué à l’échec. Un échec mortel, car il n’existe pas de deuxième chance de convaincre l’ensemble des directions générales, financières et métier de révolutionner encore l’architecture du SI. Une SOA mal née et mal gérée risque de rigidifier ce qui doit être assoupli et de complexifier ce qui doit être simplifié.

Salon MED-IT 03, 04 & 05 novembre 2009

XCOM Events, filiale d’XCOM France, Organisateur de salons Professionnels spécialisés IT, organise le Salon MED-IT, 1er Salon Professionnel IT d’envergure Méditerranéenne au Maroc les 03, 04 & 05 novembre 2009 à l’Office des Changes de Casablanca avec comme Partenaire Officiel l’Apebi, Fédération Marocaine des Technologies de l’Information, des Télécommunications et de l’Offshoring.

Visitez ce site : http://www.med-it.com

BPM/Urbanisation du SI : faut-il modéliser l’existant ?

Vous connaissez peut-être le principe de Peter. En résumé, c’est un principe qui dit que chaque personne tend à s’élever jusqu’au poste où elle est incompétente. L’une des variations de ce principe s’appelle l’incompétence par l’informatique et dit que :

• quelqu’un d’incompétent ne deviendra pas compétent si on lui colle un ordinateur,
• quelqu’un de compétent peut devenir incompétent avec un ordinateur.

Au delà du clin d’œil et pour revenir au sujet, l’ordinateur ou l’outil de modélisation ne fera qu’amplifier vos choix, fussent-ils bons ou mauvais. C’est pourquoi, le périmètre d’un projet processus ou d’urbanisation du SI est aussi important que la méthode qui sera utilisée pour décrire ces éléments dans le référentiel : il cadre le projet.

L’un des premières et inévitables questions concernera l’existant, le patrimoine (legacy) : faut-il le modéliser ? Faut-il capturer son fonctionnement, son essence ?

Il n’y a pas de réponse universelle car la question est trop générale.

Les mauvaises raisons pour modéliser l’existant

• Créer une documentation (temps passé*taux d’utilisation de la documentation = quelque chose proche de 0)
• Comprendre l’existant (question trop vague, particulièrement côté IT)
• Démontrer la capacité de l’outil (c’est l’éditeur qui sera content)
• Démontrer l’intelligence de l’équipe de modélisation (c’est le consultant qui sera content)

N’essayez pas de faire bouillir l’océan !

Les bonnes raisons pour modéliser l’existant

• Trouver une réponse à une question précise (confirmer/infirmer une hypothèse de la roadmap)
• Préparer un changement sur un périmètre défini
• Trouver un problème dans un domaine précis (diagnostique)

Savoir pourquoi on le fait

Le fait de disposer d’un patrimoine ne signifie absolument pas qu’il doit être modélisé. Il n’y a donc aucun impératif naturel à modéliser l’existant dans le seul but d’immortaliser son existence !

Comme pour n’importe quel projet de modélisation, sans objectif vous êtes condamné à modéliser trop en détail ou trop peu tout ceci pendant trop de temps. Si vous ne savez pas pourquoi vous le faites, vous ne saurez pas quand vous arrêter.

Un tel projet peu être catastrophique : dépense d’énergie et de ressources importantes, perte d’intérêt voir défiance envers le fait même de modéliser.

Il faut donc savoir pourquoi on le fait. Il y a de bonnes chances qu’un tel projet soit lancé pour apporter des réponses nécessaires à quelqu’un dans l’entreprise. Trouvez-le !

Être méthodique

Partir sur de bonnes bases est essentiel. Si un projet démarre sur de mauvaises suppositions, tous les modèles vont être influencés par ces suppositions.

Définissez ce que vous cherchez

Partant de la question de départ, il y a généralement 2 possibilités :

1. la réponse n’est pas identifiée
2. il y a une début de réponse mais elle est si incertaine ou imprécise que l’information n’est pas utile

Se laisser du temps

La modélisation en général est un travail itératif : la bonne réponse n’arrive que très rarement dès la première fois. La modélisation de l’existant l’est tout autant et le fait de s’attaquer à quelque chose d’existant ne facilite par le travail de modélisation pour une raison simple : la réalité est souvent beaucoup plus complexe que ce que l’on aurait décrit dans un modèle cible (donc n’ayant pas encore de réalité). La réalité n’apparaît jamais en une seule fois dès le premier modèle.

La modélisation de l’existant crée une charge supplémentaire qu’il ne faut pas négliger : celle de la mise à jour.  Chaque modèle devra être surveillé par un responsable afin d’être certain que le modèle décrit toujours la réalité. Un modèle dépassé perd beaucoup de sa valeur (voir toute sa valeur).

En clair, si vous voulez définir un To Be (votre cible), il est préférable d’avoir un As Is (existant) pour mesurer la différence et surtout pourvoir l’expliquer aux équipes qui exécutent le processus : « Qu’est-ce qui va changer ? ».

Cela permet aussi d’affiner ses réponses concernant la faisabilité de l’objectif et la probabilité de l’atteindre.

Modéliser l’existant est donc parfois nécessaire. N’ignorez pas la charge implicite que cela amène sur les épaules des responsables de processus.

SOA – Architecture Orientée Service

Le système d’information de l’entreprise est généralement constitué d’applications et de données constituant son héritage (en anglais legacy). Avec les fusions de groupe, l’évolution des technologies, cet héritage a tendance à devenir hétérogène et à se spécialiser par métier (entité, service, etc.), ce qui provoque un fonctionnement en silo, c’est-à-dire un cloisonnement des différents métiers empêchant certaines formes de transversalité et masquant au décideur une vision globale du système d’information de son entreprise.

L’intégration des applications de l’entreprise (EAI) est une solution à ce problème. Elle consiste à développer des connecteurs spécifiques permettant de faire communiquer entre-eux les différents silos de l’entreprise.

Architecture orientée service

Une architecture orientée services (notée SOA pour Services Oriented Architecture) est une architecture logicielle s’appuyant sur un ensemble de services simples.

L’objectif d’une architecture orientée services est donc de décomposer une fonctionnalité en un ensemble de fonctions basiques, appelées services, fournies par des composants et de décrire finement le schéma d’interaction entre ces services.

L’idée sous-jacente est de cesser de construire la vie de l’entreprise autour d’applications pour faire en sorte de construire une architecture logicielle globale décomposées en services correspondant aux processus métiers de l’entreprise.

Lorsque l’architecture SOA s’appuie sur des web services, on parle alors de WSOA, pour Web Services Oriented Architecture).

Principes généraux d’une architecture orientée service

Il n’existe pas à proprement parler de spécifications officielles d’une architecture SOA, néanmoins les principales notions fédératrices que l’on retrouve dans une telle architecture sont les suivantes :

• La notion de service, c’est-à-dire une fonction encapsulée dans un composant que l’on peut interroger à l’aide d’une requête composée d’un ou plusieurs paramètres et fournissant une ou plusieurs réponses. Idéalement chaque service doit être indépendant des autres afin de garantir sa réutilisabilité et son interopérabilité.
• La description du service, consistant à décrire les paramètres d’entrée du service et le format et le type des données retournées. Le principal format de description de services est WSDL (Web Services Description Language), normalisé par le W3C.
• La publication (en anglais advertising) et la découverte (discovery) des services. La publication consiste à publier dans un registre (en anglais registry ou repository) les services disponibles aux utilisateurs, tandis que la notion de découverte recouvre la possibilité de rechercher un service parmi ceux qui ont été publiés. Le principal standard utilisé est UDDI (Universal Description Discovery and Integration), normalisé par l’OASIS.
• L’invocation, représentant la connexion et l’interaction du client avec le service. Le principal protocole utilisé pour l’invocation de services est SOAP (Simple Object Access Protocol).

Avantages d’une architecture orientée service

Une architecture orientée services permet d’obtenir tous les avantages d’une architecture client-serveur et notamment :

• Une modularité permettant de remplacer facilement un composant (service) par un autre
• Une réutilisabilité possible des composants (par opposition à une système tout-en-un fait sur mesure pour une organisation).
• De meilleures possibilités d’évolution (il suffit de faire évoluer un service ou d’ajouter un nouveau service)
• Une plus grande tolérance aux pannes
• Une maintenance facilitée

Urbanisation SI

L’urbanisation consiste à découper le SI en modules autonomes, de taille de plus en plus petite :

• les zones,
• les quartiers (et les îlots si nécessaire),
• les blocs (blocs fonctionnels).

Entre chaque module (zone, quartier, îlot, bloc) se dessinent des zones d’échange d’informations qui permettent de découpler les différents modules pour qu’ils puissent évoluer séparément tout en conservant leur capacité à interagir avec le reste du système.

Plus particulièrement, l’urbanisation vise :

• à renforcer la capacité à construire et à intégrer des sous-systèmes d’origines diverses,
• à renforcer la capacité à faire interagir les sous-systèmes du SI et les faire interagir avec d’autres SI (interopérabilité),
• à renforcer la capacité à pouvoir remplacer certains de ces sous-systèmes (interchangeabilité).

et de manière générale pour le SI à :

• favoriser son évolutivité, sa pérennité et son indépendance,
• renforcer sa capacité à intégrer des solutions hétérogènes (progiciels, éléments de différentes plate-formes, etc.).

L’Urbaniste doit participer au projet…

Je parle par expérience. Pour détecter le mauvais Urbaniste, comme pour faciliter la prise en compte des propositions d’urbanisme dans les projets, une seule solution : l’immersion.

Prenez un Urbaniste compétent, qui a le souci de donner à chaque projet des clefs pour son intégration dans le SI. Mettez-le dans le projet, très en amont, avec des propositions prêtes à l’emploi (mais non gravées dans le marbre) pour faciliter la description des interfaces du produit. Cet Urbaniste aura préparé une déclinaison du Plan d’Urbanisme SI pour ce projet. Il aura entre les mains quelques modèles de processus et de données (qu’il aura captés chez les métiers). Mettez-le en contributeur actif des spécifications d’interface, d’échanges, de flux, d’intégration avec le reste du SI, etc. Demandez-lui aussi de participer au lotissement du projet, des phases de mise en œuvre du produit, etc.

Une fois ces spécifications réalisées, laissez l’Urbaniste dans le projet. Un bon urbaniste doit comprendre ce qu’il doit proposer, et pourquoi ses propositions seront confirmées ou abandonnées. Un très bon Urbaniste comprendra avant-même le projet quelles propositions d’urbanisme pourront être apportées à un projet, en fonction du contexte, en fonction du budget, de l’urgence opérationnelle, etc.

Inversement, il y a des équipiers projets qui ne veulent pas écouter ce que l’Urbaniste a à dire, et pourquoi il le dit. Tout acteur du projet devra comprendre qu’il n’est pas seul, et que le fruit de son projet doit s’inscrire avec un succès durable dans un SI existant, ce qui exprime les raisons et motivations des Urbanistes. Le projet (le build) est une phase transitoire, le produit (le run) est une phase plus longue : les opérationnels – les métiers – vivent des produits, et non des projets.

Idéalement, l’acteur projet sera immergé une fois de temps en temps dans la cellule d’Urbanisme : il participera à la construction du plan d’urbanisme, il réfléchira aux notions d’interface, aux questions autour des modèles, et apportera sa contribution à l’Urbanisme.

En conclusion

Notre métier d’Urbaniste est souvent mal vécu par les « opérationnels », alors que les objectifs sont à l’origine les mêmes : un SI efficace répondant aux besoins et enjeux stratégiques. Il n’y a pas d’Urbanisme sans projet.

Un conseil aux Urbanistes : soyez d’abord un opérationnel, réalisez des projets, avant de vous mettre à l’Urbanisme. Puis revenez souvent au projet.

Un conseil aux acteurs projet : ne confondez pas pieds sur terre et terre à terre (le premier est nécessaire, le second est néfaste). Pensez-y : les Urbanistes sont le plus souvent issus des projets, et y replongent régulièrement (si ce n’est pas le cas, invitez-les !).

Dans l’univers de l’entreprise où tout va très vite, et où le SI est un partenaire incontournable, il faut conserver une vision long terme, une sorte de sang-froid, qui permet de définir et de maintenir un cap. C’est un peu le rôle de l’Urbaniste, et c’est aussi pour cela qu’il est parfois incompris. Mais il est nécessaire.

Introduction aux différents concepts

Urbaniser un système d’information permet d’atteindre trois objectifs :

• Fédérer les briques d’un système autour d’une architecture d’ensemble pour acquérir souplesse et réactivité afin de s’adapter plus facilement aux contraintes du marché.

• Permettre la prise en compte rapide et efficiente des demandes d’évolution critique de manière rationnelle.

• Porter les efforts de développement sur les nouvelles fonctionnalités à forte valeur ajoutée tout en essayant au maximum de réutiliser le système existant.

Une fois le système urbanisé, les modifications apportées n’auront qu’un impact prévisible et celui-ci pourra être maîtrisé. La démarche d’urbanisation propose de passer d’un système d’information existant à un système d’information cible, par paliers successifs, correspondant à des états stables. Ceci dans le but de limiter et maîtriser les risques par rapport à une approche plus radicale qui consisterait à passer d’un système à un autre à un instant t.

Urbaniser un système d’information nécessite plusieurs étapes basées sur un cadre de référence de quatre visions du système d’information:

• La vision métier

C’est la cartographie métier qui décrit l’ensemble des activités que le système
d’information doit supporter.

• La vision fonctionnelle

Elle décrit l’ensemble des fonctions du système d’information permettant de supporter les processus métier.

• La vision applicative

L’ensemble des éléments applicatifs du système d’information.

• La vision technique

L’ensemble des matériels, logiciels de base et technologies utilisées.