crossbase | Réalisation réussie du projet « Product Finder 2.0

Waldachtal, le 27/10/2016 : La mutation d’un simple atelier souabe en PME active à l’international : c’est ainsi que l’on pourrait décrire l’évolution du groupe fischer depuis sa fondation en 1948. Pourtant, l’entreprise familiale est toujours restée fidèle à ses origines : son siège se trouve toujours à Waldachtal-Tumlingen, dans le nord de la Forêt-Noire, à quelques 60 km au sud-ouest de Stuttgart.

Forte de ses capacités d’innovation qui l’ont sans cesse poussée à non seulement concevoir de nouveaux produits, mais aussi à défricher de nouveaux champs d’activités, la société couvre aujourd’hui les secteurs Systèmes de fixation, Systèmes automobiles, Technologie et Consulting.

Fonctions centrales de la solution

Le projet Produkt Finder 2.0

Les rayons de produits tels qu’on les retrouve dans la plupart des magasins de bricolage ou de construction sont généralement structurés d’après le processus de sélection du client. Ainsi, les goujons sont d’abord classés par application, puis répartis selon les différents groupes de matériaux grâce à un système de code couleur bien visible : vert pour les goujons universels, jaune pour la maçonnerie et les matériaux pleins, bleu pour les panneaux et les cavités, gris pour le béton et blanc pour les applications spéciales.

Ce concept est désormais complété par un système qui simplifie grandement la sélection des produits. Une application spéciale accessible sur place depuis un terminal guide l’utilisateur dans un processus de choix assisté pour lui permettre d’identifier rapidement la solution de fixation qui lui convient. Un magasin pilote propose même un signal lumineux qui indique l’emplacement du produit ainsi identifié, directement dans le rayon. Les données nécessaires à cette application sont fournies sur le serveur API de crossbase.

Le serveur API de crossbase

Avec l'aide du serveur API, des applications tierces peuvent lire ou écrire les informations de la base de données crossbase. Par exemple, les données sur les produits, les fichiers médias, les textes et les traductions ainsi que la terminologie peuvent être consultés. Contrairement aux requêtes SQL directes, ces interfaces peuvent être utilisées pour garantir que les accès sont toujours fonctionnels avec chaque version actuelle de la base de données et pour récupérer des informations actualisées. Grâce à l'interface, les développeurs de logiciels expérimentés peuvent écrire des applications qui récupèrent les données de la base de données crossbase avec peu d'efforts. Les services peuvent être interrogés par REST.

Entretien avec le chef de projet chez fischer

Monsieur Müller, pourriez-vous nous décrire brièvement le projet Product Finder 2.0 ?
Le but de ce projet était de faciliter davantage le processus de sélection de nos produits dans les zones de libre-service des magasins de bricolage et de rénovation. L'amateur de bricolage peut rapidement trouver le bon produit, par exemple, une fixation adaptée pour une armoire murale, grâce à une application appropriée qui soutient le processus de sélection par des questions guidées. En raison du grand nombre de produits que le client trouve sur les présentoirs des produits fischer, nous avons voulu aller plus loin...

... en pensant au bricoleur perdu devant un mur de produits ?
Oui, exactement. Grâce à l'application, il sait maintenant quel produit lui convient, mais ne sait toujours pas où le trouver.

Quelle était la solution ?
Pour le bricoleur, la solution est assez simple. La position exacte de l'article est indiquée sur l'étagère du présentoir par un signal lumineux LED. Grâce à la coopération avec l'entreprise findbox, qui propose des solutions standardisées à cet effet, la solution technique et infrastructurelle était littéralement "à portée de main" et nous avons pu commencer les premiers tests en peu de temps.

En arrière-plan, un tel système doit être alimenté en données ...
Oui, la question de savoir comment obtenir les données nécessaires et les rendre disponibles est au moins aussi importante que la présentation des données. Il a vite été évident que la base de données crossbase, qui contient toutes les informations relatives au marketing des produits, est notre source de données centrale à cet effet.

Quelle était la raison de l'utilisation du serveur API crossbase pour ce projet ?
Nous comptons sur crossbase depuis 15 ans. La solution est stratégiquement ancrée chez fischer et est utilisée pour la production de catalogues imprimés et électroniques, entre autres. En outre, les services de médias internes et externes fonctionnent via crossbase. Il était important pour nous d'établir une solution durable et standardisée qui soit technologiquement à jour. Il était donc logique d'utiliser le serveur API à cette fin, qui fournit REST comme technologie d'interface.

Qui était responsable de la mise en œuvre du frontend ?
Fischer a chargé une agence aux Pays-Bas de mettre en œuvre le frontend. Les données pertinentes sont fournies par un logiciel intermédiaire développé chez fischer, qui récupère les données de crossbase.

Comment la coopération entre fischer, l'agence et crossbase s'est-elle déroulée ?
Comme nous nous sommes concertés avec les deux prestataires de services à un stade précoce - entre autres pour la définition de l'infrastructure et la définition des objets de transfert de données nécessaires - il n'y a pas eu de frictions. D'autant plus que toutes les définitions et les demandes de changement ont été étroitement coordonnées et enregistrées dans une documentation centrale. Les techniciens et les chefs de projet de tous les participants se sont assis autour d'une table lors des deux ateliers et, au final, tous les délais et le budget de réalisation ont été respectés à cent pour cent.

Y a-t-il eu des difficultés ?
Une planification détaillée et un concept étroitement coordonné ne suffisent pas toujours : la théorie finit par céder sa place à la pratique ! Tout ne peut pas être planifié à cent pour cent. Mais là aussi, crossbase s'est montré très flexible lorsqu'il s'est agi de mettre en œuvre des modifications du concept dans des délais très courts. En outre, au début du projet et pendant la phase de test, une attention particulière a été accordée au bon fonctionnement des services. Les problèmes de performance qui se sont posés dans certaines constellations lors de l'opération de test avec des données réelles ont été optimisés par crossbase dans le temps.

Quels sont vos conseils à partir de l'expérience du projet ?
Dans tous les cas, il est important de planifier à l'avance et, surtout, de réunir tous les prestataires de services concernés à un stade précoce.

Y a-t-il d'autres plans pour utiliser le serveur API ?
Oui, le serveur API est une solution universellement applicable qui crée de nombreuses nouvelles possibilités. En outre, il s'agit bien entendu d'un investissement que nous voulons utiliser sur une large base et que nous continuerons donc à développer. Fondamentalement, je vois de nombreuses autres possibilités d'application chez fischer, par exemple une interface vers nexMart est actuellement en projet.

M. Müller, merci beaucoup pour cette interview et nous vous souhaitons beaucoup de succès pour les projets à venir !

L'interview a été menée par Katrin Schenker, responsable marketing chez crossbase