C’est un fait rare, voire inexistant de trouver une solution technologique qui réponde en tout point aux besoins de l’utilisateur. Dès lors, deux options sont à étudier : soit l’utilisateur s’adapte au standard, soit l’utilisateur opte pour le recours à des développements spécifiques ou additionnels. L’une comme l’autre offrent des avantages et des inconvénients. Par exemple, la facilité d’implémentation versus la complexification du process client dans le premier cas ou une prise en main facilitée versus l’association standard/spécifique à maintenir.

Néanmoins, une troisième voie existe : intégrer les besoins spécifiques dans le développement continu de la solution. Celle-ci semble être la bonne réponse autant pour l’utilisateur que l’éditeur. Le premier dispose d’une solution en adéquation avec ses besoins et le second, en faisant évoluer sa solution, met à disposition de ses autres clients une solution plus performante et aboutie qui pourrait aussi satisfaire leurs propres attentes.

Pourtant, cela n’est pas toujours évident. Sous le triptyque Qualité, Délai et Coût, des problématiques et arbitrages apparaissent. Comment s’assurer que la solution évolue au rythme des besoins utilisateur ?

C’est dans ce contexte que OneTeam a accompagné un de ses clients dans un rôle de coordinateur éditeur-marque visant à concilier les intérêts des parties prenantes qui pouvaient parfois être divergents.

La mobilité en magasin, une priorité retail

La présentation du projet client

Le projet a pour vocation de développer la mobilité du vendeur en boutique. L’objectif était de lui permettre d’accompagner son client tout au long de son parcours d’achat, de lui offrir des conseils personnalisés et de répondre à ses attentes à l’aide d’une application. Cette dernière développée sur-mesure par le client est connectée en temps réel une application avec la solution POS de l’éditeur. Au début de l’intervention de OneTeam, cette application mobile possédait déjà plusieurs fonctionnalités. D’une part, la partie CRM permet aux équipes de vente de consulter le fichier client, d’en créer de nouveaux, de modifier les existants et d’avoir accès à l’historique des ventes de ces derniers. D’autre part, les vendeurs ont aussi la capacité de consulter le catalogue produits et la disponibilité des articles depuis l’application. Ces fonctionnalités sont rendues possibles grâce aux API mis à disposition par la solution POS.

De l’avant-vente à la vente

Ainsi, il apparait que l’application « maison » offre aux boutiques de couvrir l’expérience d’avant-vente : l’identification du client et de ses préférences d’achat, la sélection des articles et le contrôle des stocks en boutique ou au sein du réseau. Le vendeur améliore la qualité de son service et des conseils qu’il prodigue. Il est plus à même de personnaliser sa relation avec le client, grâce aux données dont il dispose depuis l’application et à identifier plus rapidement les produits qui pourraient intéresser le client tout en sachant s’il est en mesure de les lui vendre. Les temps d’attente sont réduits, l’expérience plus personnalisée est aussi plus fluide.

Afin d’offrir une expérience d’achat 100% mobile, il manque l’étape transactionnelle à cette application. Jusqu’alors, l’application pouvait générer une pré-vente, c’est-à-dire enregistrer un panier d’article attaché à un client donné mais cette pré-vente devait nécessairement être envoyée à la solution éditeur qui permettait depuis une caisse, de réaliser l’étape de paiement et d’enregistrer le document de vente final. C’est cette ultime étape du cycle de vente qui mobilise l’ensemble des discussions.

La stratégie client

En cohérence avec l’orientation «mobilité» prise par le client, la finalisation de la transaction depuis l’application maison est donc un besoin central devenu principal à mesure que les autres fonctionnalités ont été déployées. Conscient de la haute complexité technique liée à cette fonctionnalité, le client ne souhaite pas recourir au développement spécifique qui serait lourd à supporter et à maintenir en cohérence avec le standard.

De même, le client cherche à rationaliser ses coûts vis-à-vis de ses fournisseurs, évidemment, mais aussi vis-à-vis de ses différentes marques/maisons. Ainsi, afin de pouvoir inclure cette fonctionnalité dans le standard de l’éditeur, il est nécessaire de mutualiser les besoins propres à chacune de marques en les rationalisant d’une part et en les priorisant d’autre part.

Des ateliers métiers mais aussi technico-fonctionnels ont été menés dans l’objectif de définir un flux transactionnel fluide et compatible avec les applications tierces que possèdent le client. Ce flux inclut des développements sur la ou les applications tierces mais en limite aussi la charge et la maintenance. Côté éditeur, le flux proposé devient « standardisable » et peut profiter à d’autres clients demandeurs.

Les réflexions de l’éditeur

L’état des lieux

Au départ du projet, l’éditeur n’était pas techniquement en mesure d’offrir cette fonctionnalité alors qu’elle était très attendue par le client. A cette considération technique s’ajoutent des discussions d’ordre stratégique pour l’éditeur.

La faisabilité technique à l’étude

D’un point de vue purement technique, la partie transactionnelle est toujours complexe à traiter. En effet, cela requiert des développements structurants et sensibles qui ne sont pas ou très peu mutualisables au niveau mondial. Les enregistrements de vente sont soumis à des contraintes fiscales qui varient en fonction des pays.

Permettre à une application tierce de réaliser une vente qui soit complète et légale implique également plusieurs communications avec la solution éditeur : une première pour récupérer les taxes à appliquer, une deuxième pour enregistrer/fiscaliser la transaction après paiement et une dernière pour récupérer le ticket et être en mesure de l’imprimer depuis l’application.

Le coût de développements lié à cette ouverture et à la localisation est de fait conséquent pour l’éditeur auquel il faut ajouter celui qui sera à prendre en compte dans la maintenance évolutive liée aux développements choisis par l’éditeur ou contraints par les mesures étatiques.

Des choix stratégiques en question

D’un point de vue stratégique, ouvrir sa solution à des applications tierces sur cette partie centrale de l’activité retail peut fragiliser le business model de l’éditeur. Il donne le droit à d’autres de faire des opérations qu’il était jusqu’alors le seul à pouvoir réaliser. En déléguant une partie de l’étape de vente, il s’expose à une diminution possible du nombre d’utilisateurs et donc à une perte de profit.

A l’inverse, ce besoin d’ouverture n’a pas seulement été émis par ce seul client, d’autres avaient également évoqué le besoin de pouvoir réaliser un cycle de vente complet depuis une autre application en interaction avec la solution éditeur.

De ce fait, refuser d’intégrer cette fonctionnalité dans le standard de la solution peut également fragiliser la position de l’éditeur sur le marché et à terme, lui faire perdre des clients et donc ses sources de revenus.

Un partenariat à considérer

Divergence d’intérêts ?

Si le besoin est affirmé et justifié d’un point de vue business pour le client, son intégration dans le standard éditeur ne semble pas aussi bénéfique pour ce dernier. Entre coûts de développement et de maintenance et impacts potentiels sur les licences vendues, les réticences pourraient faire avorter ce projet.

Pourtant, la mobilité, le temps réel… sont des problématiques que les éditeurs concurrents intègrent, et donc, celui-ci doit aussi se réinventer et être en mesure de répondre à ses clients pour les conserver et aussi en attirer de nouveaux, telle est la loi du marché… Des réunions de négociation et de travail ont permis d’identifier et de définir les clés d’un partenariat mutuellement bénéfique.

Ou bénéfices mutuels ?

D’une part, l’éditeur, en acceptant de développer la fonctionnalité demandée, renforce sa relation client et peut aussi tirer profit de l’expertise Retail de cet acteur. Travailler à ses côtés lui offre ainsi la possibilité d’améliorer la qualité de sa solution afin qu’elle demeure reconnue sur le marché des POS.

D’autre part, le client qui possède plusieurs applications tierces a besoin d’une fonctionnalité standard à laquelle les applications tierces devront se conformer. Cela permet d’uniformiser les interfaces et rationaliser les process.

Il apparait donc que les deux parties prenantes partagent aussi des intérêts communs vis-à-vis de cette fonctionnalité.

De plus, la fonctionnalité est financée en partie par le client en mode projet. Puis, la maintenance évolutive est soutenue pour un nouveau modèle de souscription. Aux licences applicatives, s’ajoute les frais «d’abonnement» aux services transactionnels.

Ce modèle aboutit donc à un ROI positif pour les deux parties.

La gestion de projet éditeur-client

Collecte et centralisation des besoins client

Côté métier, les demandes relatives à cette fonctionnalité sont nombreuses. Côté IT, chaque application que possède le client a ses propres contraintes et revendications. Néanmoins, le client doit assurer que la fonctionnalité à développer permette à chacune de ses applications tierces de l’utiliser en engageant le minimum d’adaptations.

Des ateliers de travail ont été organisés par OneTeam afin de collecter les besoins et d’identifier les problématiques techniques. Cela a permis de définir une solution cible et des lots de développements contenant une priorisation des besoins. Rationalisation des coûts prenant en compte le time-to-market est le maitre mot de cette gestion projet.

Ainsi les spécifications veillaient à répondre à la demande initiale: une fonctionnalité la plus standard possible qui pourrait bénéficier à d’autres clients de l’éditeur.

Une fois la solution définie, OneTeam avait la charge de piloter des réunions de suivi et de priorisations des demandes. L’objectif est de valider en interne, les choix technico-fonctionnels à soumettre à l’éditeur.

Partage et collaboration éditeur

A partir des spécifications émises par le client, l’éditeur a été en mesure de réaliser l’étude de faisabilité et de partager ses retours avec le client. Le client, expert métier et l’éditeur, expert technologique collaborent afin de mettre au point la fonctionnalité demandée tout en veillant à répondre aux intérêts de chacun : des arbitrages ont donné lieu à des revues des priorités et une adaptation des plannings de livraison (et donc de déploiement). Cela permet d’assurer la convergence d’intérêts client-éditeur.

Les suivis de développement ont été assurés par OneTeam en collaboration avec l’éditeur afin de s’assurer du respect des plannings et de pouvoir réagir de manière pro-active, en cas de retard ou problématiques rencontrées. La phase de test a été réalisée avec une présence forte de l’éditeur pour faciliter la prise en main de la fonctionnalité par le client et d’être efficace en cas de bugs constatés.

Les résultats positifs et un engouement réel

Un projet réussi…

Après plusieurs mois de projet, une première version de la fonctionnalité a été livrée par l’éditeur qui a été déployée par le client. Deux applications sont aujourd’hui capables de gérer la totalité du process d’achat : client – produit – encaissement.

Dès les premières utilisations, les vendeurs étaient unanimes : la solution est fluide, facile à prendre en main et rapide. Elle améliore de manière significative l’expérience client : le vendeur est dédié au client et est en mesure de l’accompagner tout au long du cycle de vente avec des conseils personnalisés et un encaissement de proximité en évitant le «passage à la caisse».

… Evolutions et roll-out en cours

Riche de ce premier succès, le partenariat avec l’éditeur POS en sort renforcé et le groupe souhaite de manière claire poursuivre les développements afin de déployer cette fonctionnalité sur ses différents marchés et à l’échelle internationale. Cela implique des développements certes conséquents pour l’éditeur mais qui restent moteur pour enrichir sa solution d’une fonctionnalité utilisable par le plus grand nombre grâce à un modèle de coûts cohérent avec ses objectifs de croissance.