Projet ANR 2011 - BR4CP (Business Recommendation for Configurable products) Rapport d'analyse des besoins Janvier 2013 Rapport IRIT/RR--2013-17 FR Redacteur : 0. Lhomme
Introduction...4 La configuration interactive...4 Le projet BR4CP...4 Analyse des besoins...4 1 - Expression des besoins...5 1.1 Fonctions principales d un système de configuration...5 1.2 Caractérisation de l'ensemble des configurations encore atteignables...5 1.3 Variables particulières...5 1.4 Ordre libre, ordre contraint, ordre partiellement contraint...6 1.5 Suggestions de choix...6 1.6 Optionalité, variables d'existence...6 1.7 Packs...6 1.8 Contraintes en extension...6 1.9 Choix non compatible...7 1.10 Identification des choix à remettre en cause...7 1.11 Remise en cause de choix effectués...7 1.12 Conseils / suggestions lors d une remise en cause...7 1.13 Auto complétion...7 1.14 Suggestions et préférences...8 1.15 Outils de développement d une application de configuration...8 1.16 Algorithmique des solveurs de configuration...8 1.17 Environnement des solveurs de configuration...9 1.18 Besoins pédagogiques...9 1.19 Prise en compte des comportements de l utilisateur...9 1.20 Symétries...9 2 - Classement des différents besoins...10
Figure 1...12
Introduction Une tendance générale dans la relation commerciale, que le produit concerné soit un bien matériel ou un service, est de proposer à l acheteur plus de possibilités, plus de choix. La configuration interactive Lorsque le produit fait intervenir plusieurs caractéristiques interdépendantes, la combinatoire des possibilités peut être difficile à appréhender par un acheteur, voire même par un vendeur spécialisé dans cette gamme de produits. Les systèmes de configuration interactive («sales configurator») ont pour rôle d aider acheteur et vendeur à se déplacer dans cet espace de choix. Les différents choix possibles ainsi que les différentes règles de compatibilité entre ces choix doivent être définis précisément et forment le modèle de configuration. Une fois ce modèle établi, il va permettre à un système de configuration interactive d interagir avec un acheteur, de gérer ses requêtes (qui typiquement restreignent partiellement certains des prochains choix possibles) et d émettre des propositions de produits complets. Le projet BR4CP Le projet BR4CP ambitionne d améliorer l algorithmique des systèmes de configuration interactive sous plusieurs aspects. En particulier, le projet aborde la question de la pertinence des propositions émises par un système de configuration, et propose comme thème fédérateur de s inspirer des systèmes de recommandations, largement utilisés dans la vente de produits standardisés. Analyse des besoins La première partie de ce rapport d analyse des besoins présente les besoins que les partenaires du projet ont rencontrés lors de diverses réalisations de systèmes de configuration. La seconde partie fait ressortir une structure matricielle de ces besoins, qui nous permet de classer précisément les différents besoins, et permettra de positionner les travaux des partenaires du projet.
1 - Expression des besoins Différentes applications de configuration, ainsi que différents solveurs génériques de problèmes de configuration ont été développés depuis plusieurs années par les partenaires du projet BR4CP. Nous insistons dans cette partie sur les fonctionnalités qui ont été importantes dans ces développements, et qui ont, en général, déjà été réalisées à plusieurs reprises, ainsi que sur des besoins qui n ont pas été toujours bien pris en compte. Les besoins étant étroitement liés aux fonctionnalités, nous les présenterons de manière conjointe sans forcément différencier les fonctionnalités déjà réalisées et les besoins ressentis mais pour l instant jamais pris en compte. Le terme de configuration regroupe une très grande variété de problèmes, et nous nous focalisons dans cette analyse des besoins sur les problèmes de configuration interactive. 1.1 Fonctions principales d un système de configuration L'évaluation de l'impact du choix d'un utilisateur sur l'espace des configurations possibles, ainsi que la présentation qui en est faite à l'utilisateur sont probablement les fonctionnalités principales d'un outil de configuration en ligne. Toutes les autres fonctionnalités en dérivent plus ou moins directement, qu'elles soient postérieures au choix proprement dit (impact sur le coût, ou encore la compatibilité avec d'autres options à choisir par exemple) ou bien qu'elles se positionnent en amont de ce choix (aide à la décision de l'utilisateur). 1.2 Caractérisation de l'ensemble des configurations encore atteignables Un élément indispensable d un système de configuration interactif est, après une série de choix de l'utilisateur, de différencier les futurs choix encore possibles des choix désormais interdits (tout au moins sans remise en cause des précédents choix). Ce besoin peut s avérer être trop coûteux en temps de calcul pour certains modèles de configuration (il correspond à calculer la projection exacte de l'ensemble des configurations possibles sur les domaines des valeurs possibles des différentes variables du problème). Pour donner une évaluation rapide des possibilités restantes après une série de choix de l'utilisateur, il peut être parfois nécessaire de calculer une simple approximation de l'espace des configurations possibles 1.3 Variables particulières Certaines variables comme le prix peuvent avoir droit à un traitement particulier: du fait de la nature numérique de cette valeur, et de la préférence commune d'un utilisateur vers les prix les plus bas, il est généralement suffisant de calculer non pas tous les prix possibles mais seulement le prix minimal encore atteignable à partir de l'ensemble courant des choix de l'utilisateur. D'autres variables jouent un rôle particulier: les délais de livraison peuvent être fortement dépendants de la configuration choisie, mais aussi du moment où la configuration a lieu. Par exemple, tant qu'il reste au moins un créneau dans le mois pour réaliser le produit configuré,
le délai pourra sembler acceptable à l'acheteur. Si à un moment donné, plus aucun créneau n'est disponible, le délai pourra devenir inacceptable et entrainer le choix d'une toute autre configuration. La fragilité/robustesse d une configuration donnée repose donc en grande partie sur cette notion de délai. 1.4 Ordre libre, ordre contraint, ordre partiellement contraint Concernant les choix faits par l'utilisateur, suivant les applications, l'ordre entre les variables pour lesquelles on doit choisir une valeur peut être entièrement libre, totalement fixé au départ, ou être partiellement contraint. 1.5 Suggestions de choix Dans certaines applications de configuration, le système de configuration doit aider l'utilisateur à faire un choix. Le système doit ainsi prendre en compte : - une connaissance de l'utilisateur (ses préférences, ses choix passés, ses déclarations, les actions d utilisateurs similaires, etc.) - et une connaissance du fournisseur du produit à configurer (ses politiques de ventes, ses historiques, etc.) Voir le paragraphe sur les suggestions et préférences 1.6 Optionalité, variables d'existence Certains choix utilisateurs peuvent éventuellement être proposés dynamiquement en fonction des choix précédents. Cet aspect est lié, plus généralement, à l'existence, dans certaines applications de configuration, de sous problèmes devant être générés dynamiquement (et automatiquement) en fonction de la valeur que prennent certaines variables. Ces variables d'existence permettent de raisonner sur la présence ou non de ces sous problèmes. Un autre problème est celui des variables chargées dynamiquement : pour des raisons de performance, il n'est parfois pas possible de charger la totalité d'un problème de configuration. 1.7 Packs Une notion de pack est parfois utilisée: un pack permet par exemple de tenir compte du fait que le prix d'un ensemble d'options données pour un véhicule est en fait différent de la somme des prix des options en question (a priori plus bas). 1.8 Contraintes en extension Un type de contrainte important en configuration est la contrainte définie en extension par un ensemble de tuples. Elle spécifie par exemple les caractéristiques de différents types de produit en jouant le rôle d un catalogue, ou encore les compatibilités ou incompatibilités entre composants. Cette contrainte est souvent appelée contrainte de table.
1.9 Choix non compatible Dans certaines applications de configuration, un choix qui n'est plus compatible avec l'ensemble de choix courant de l'utilisateur peut quand même être proposé par le système, avec par exemple une couleur différente pour le distinguer des choix restant compatibles. Un tel choix incompatible entraine une remise en question de certains des choix précédents de l'utilisateur. On peut aussi vouloir distinguer différents degrés d incompatibilité. 1.10 Identification des choix à remettre en cause Le système de configuration doit être capable d'identifier les choix à remettre en cause suite à un choix incompatible. 1.11 Remise en cause de choix effectués Le système de configuration doit aussi être capable de prendre en compte cette remise en cause une fois la correction de l utilisateur effectuée. 1.12 Conseils / suggestions lors d une remise en cause Dans certains cas, suite à un choix incompatible, l utilisateur a un besoin de conseil: il peut y avoir de nombreuses possibilités de remise en cause des choix courants afin de rendre cet ensemble cohérent avec le choix incompatible que l'utilisateur veut forcer. Dans ce cas, on attend du système de configuration qu'il propose des suggestions pour remettre en cause les précédents choix de façon pertinente. Voir le paragraphe sur les suggestions et préférences. 1.13 Auto complétion Le système de configuration a souvent besoin de compléter une configuration partielle, définie à partir des choix utilisateurs, afin de proposer une configuration complète. Pour cela, différents aspects sont à prendre en compte. Les contraintes du problème doivent bien entendu être vérifiées par les configurations complètes proposées par le système, ce qui positionne ce besoin dans la problématique de la recherche de solution dans un espace combinatoire. Cependant, l auto complétion ne se réduit pas à cette problématique : en général, on ne souhaite pas présenter à l utilisateur une solution quelconque mais une «bonne» solution, tenant compte des préférences de l'utilisateur et des préférences du fournisseur du produit configuré (voir le paragraphe sur les suggestions et préférences). Il est parfois possible de caractériser précisément l optimalité d une solution, et de se ramener à un problème d optimisation, mais il peut être particulièrement difficile à résoudre. Plus souvent, la définition d une «bonne» solution est plus floue, et calculer une solution optimale pour un critère non totalement spécifié ne fait pas grand sens ; on peut alors utiliser des approches plus liées à la structure du problème. En termes de performances, juste pour donner un ordre de grandeur des temps de réponse attendus, le système de configuration d un des partenaires du projet traite environ 2 millions d auto complétions par jour.
1.14 Suggestions et préférences Un besoin commun à différentes fonctionnalités d un système de configuration est celui de la pertinence du système de configuration lors de ses interactions de conseil à l utilisateur. C est un besoin multiforme, peu spécifié, et très ouvert, en particulier parce qu il correspond à de nouvelles façons d approcher les problèmes de configuration. Les recommandations/suggestions fournies par le système de configuration peuvent être construites à partir des connaissances sur l utilisateur comme, par exemple, son âge, le nombre de personnes dans sa famille, ses activités. On rejoint la problématique des systèmes de recommandation (filtrage collaboratif), qui évaluent la proximité du profil de l utilisateur à d autres profils connus, et en extrapolent un comportement attendu de l utilisateur. L utilisateur peut aussi orienter les suggestions qui lui sont faites en exprimant des préférences, et les besoins en ce domaine d un système de configuration se retrouvent abordés dans des domaines de recherche déjà bien étudiés liés à l expression, à l élicitation, et au traitement des préférences. Les préférences du fournisseur des produits configurés font aussi partie des éléments importants à prendre en compte, avec des particularités notables. La connaissance des produits disponibles en stock est un bon exemple d une préférence fournisseur, qui tend à orienter les conseils de configuration en fonction de l état du stock, selon qu il faut plutôt le remplir ou en écouler rapidement une partie. Par exemple, le système de configuration peut proposer des options qui sont bien représentées dans le stock, ou suggérer une montée en gamme vers des produits en stock. Plus généralement, le fournisseur des produits configurés peut vouloir prendre en compte des historiques de vente ou bien des directives du marketing. 1.15 Outils de développement d une application de configuration De nombreux besoins se retrouvent sous ce chapeau. En effet, le développement d une application de configuration est souvent difficile. La définition du modèle de configuration, donc en amont de la configuration proprement dite, est un problème en lui-même. La conception d une stratégie d'interaction de l'utilisateur avec ce modèle n est pas non plus toujours simple. Des outils logiciels peuvent apporter une aide précieuse, notamment des outils de vérification/validation du modèle : on pourrait ainsi vérifier que toutes les options d une configuration sont bien réalisables, que les contraintes sont bien prises en compte dans les configurations générées, etc. Un besoin de méthodologie de développement pour des applications de configuration est aussi identifié : le développement d un tel outil relève autant d un développement informatique que d une modélisation mathématique, alors que les méthodologies existantes ne portent que sur l un des deux aspects. 1.16 Algorithmique des solveurs de configuration On a toujours des besoins généraux sur les solveurs: plus déclaratifs, plus robustes, traitant de plus gros problèmes.
1.17 Environnement des solveurs de configuration L environnement des solveurs de configuration est aussi plutôt pauvre. Par exemple, on pourrait définir des langages/api plus orientés vers la configuration, plus faciles à utiliser, des éditeurs syntaxiques/sémantiques, des mécanismes de feedback du solveur sur le modèle. 1.18 Besoins pédagogiques On peut aussi relever la difficulté de développement pour des applications de configuration, ce qui soulève le besoin de formation des ingénieurs qui développent une application de configuration. On a un besoin de ressources pédagogiques (exemple : recettes de modélisation) 1.19 Prise en compte des comportements de l utilisateur Les systèmes de configuration interagissent avec des humains qui ont une manière particulière d'appréhender l'espace des solutions possibles : préférences imparfaitement définies, incohérence/évolution au cours de l interaction, impossibilité d'appréhender l'ensemble des solutions de manière globale, stratégies détournées (exemple: favoriser certaines options à la place d'autres en pensant a tort que cela diminuera le prix). 1.20 Symétries De nombreuses symétries apparaissent en configuration. Par exemple, si deux sous systèmes symétriques doivent être configurés, le deuxième peut être déduit du premier et de la symétrie considérée. On économise ainsi potentiellement une nombre exponentiel de configurations.
2 - Classement des différents besoins Les différents besoins que nous avons rencontrés peuvent se positionner selon deux axes : - un axe caractérise l aspect propre à la résolution de problèmes de configuration interactive, et tient compte essentiellement des contraintes de ces problèmes. - L autre axe caractérise plutôt l aspect conseil/suggestion/recommandation attendu de la part de ces systèmes. Il porte donc plutôt sur les préférences et objectifs apparaissant dans ces problèmes. Un besoin particulier peut se représenter par des coordonnées relatives à ces deux axes. Cette représentation matricielle permet de bien montrer la richesse du croisement de l aspect résolution de problèmes de configuration et de l aspect conseil/suggestion/recommandation. Les multiples entrées de la matrice sont autant de sujets d études, qui, pour la plupart, répondent à des besoins concrets et pour certains semblent être originaux. L axe «résolution» se dérive ainsi en - «configuration partielle», - «configuration complète», - «modèle de configuration» - et ensemble vide (laissant ainsi une ligne pour les besoins indépendants de cet axe de résolution). L axe de suggestions se dérive pour sa part en - suggestions liées à l «historique» de l utilisateur ou du système, - «recommandations collaboratives», prenant en compte les comportements d une base d utilisateurs. - suggestions basées sur des «préférences», - «autres recommandations», par exemple la prise en compte du stock lors de l élaboration de suggestions. - et ensemble vide (laissant ainsi une colonne pour les besoins indépendants de cet axe de suggestions). Nous ne détaillerons pas toutes les cases de la matrice (voir la figure 1), nous faisons juste apparaitre dans les cases les besoins décrits en première partie de ce document, et décrivons quelques lignes de cette matrice pour en donner une idée générale. La ligne «configuration partielle» regroupe les thèmes :
- de cohérence des choix, par exemple, les besoins de consistance plus ou moins fortes, sur certaines variables, sur certaines valeurs, les ajouts/retraits de choix. Dans la colonne ensemble vide, c'est-à-dire sans connexions avec l axe des suggestions, on retrouve alors les problématiques classiques de la CP, de SAT, du MIP et des approches de compilation d automates. Les colonnes «suggestions» de cette ligne vont par exemple regrouper des travaux comme l identification de l effort algorithmique que l on va faire sur telle valeur en fonction par exemple du stock ou du niveau de recommandation de cette valeur. - de traitement des choix incompatibles, par exemple : analyse de conflit ; résolution manuelle, automatique, ou assistée du conflit ; notion de domaines alternatifs, qui est l ensemble de valeurs possibles dans le cas où on remettrait en cause un précédent choix, et qui peut se généraliser pour distinguer différents degrés d incompatibilité. Dans la colonne ensemble vide, c'est-à-dire sans connexions avec l axe des suggestions, on retrouve là encore alors des problématiques classiques. Les colonnes «suggestions» vont aborder par exemple des questions comme la génération de conflits préférés (dans le cas ou plusieurs conflits existent, certains sont plus importants que d'autres), ou encore l'élicitation et/ou l'utilisation de préférences pour gérer des conflits. - et d ordres des choix. La ligne «configuration complète» regroupe les thèmes : - d auto complétion d une solution partielle, par exemple, les besoins de. diversité des solutions proposées, les critères de qualité des configurations proposées prenant en compte les fonctions objectifs, les contraintes, des procédures utilisateurs spécifiant un comportement souhaité et déclenchées par des évènements particuliers. - de modifications d une configuration complète La ligne «Modèle de configuration» regroupe les thèmes : - qui utilisent la structure fine du problème de configuration considéré, par exemple le réseau de contraintes, les variables optionnelles, les packs - qui portent sur la vérification du modèle de configuration, par exemple on peut vouloir s assurer que chaque tuple d une catalogue est bien réalisable, ou vérifier des propriétés particulières sur l ensemble des configurations possibles. - de développement du modèle de configuration, par exemple, on peut vouloir trouver des descriptions minimales, compter des configurations particulières.
Figure 1 Ø Historique Suggestions Recommandation collaborative Préférences Autres 1.14 1.14 1.14 1.14 Ø Cohérence des choix 1.2, 1.6, 1.8 1.14 1.14 1.7,1.14 1.7,1.14 Configuration partielle Traitement des choix incompatibles 1.6, 1.8, 1.9,1.10, 1.11 1.5,1.10,1.12 1.14 1.5,1.10,1.12,1.14 1.5,1.7,1.10,1.12 1.14 1.5,1.7, 1.10,1.12 1.14 Configuration interactive Configuration complète Ordres des choix 1.4, 1.6, 1.8 1.4, 1.5,1.14 1.4, 1.5,1.14 1.4, 1.5,1.7,1.14 1.4, 1.5,1.7,1.14 Complétion 1.13 1.13,1.14 1.13,1.14 1.7,1.13,1.14 1.7,1.13,1.14 Modification 1.5,1.14 1.5,1.14 1.5,1.7,1.14 1.5,1.7,1.14 Structure 1.6, 1.8 1.7 Vérification 1.15 1.15 1.15 1.15 1.15 Modèle de configuration Développement 1.15,1.17, 1.18 1.15,1.17,1.18 1.15,1.17,1.18 1.15,1.17,1.18 1.15,1.17,1.18