Introduction

In industries that offer customized goods and services, which meet their customer's individual business needs, vendors are often required to employ a consultative sales strategy called "solution selling" (cf. [7]). It comprises mainly four interdependent processes carried out on a per project basis: requirements definition, customization and integration, deployment, and post-deployment support. The groundwork for these processes is laid by the vendor's sales force screening for potential customers (leads) and assessing their willingness and ability to buy a solution. This task is termed "lead qualification". Lead qualification in solution selling industries is highly dependent on a salesperson's individual knowledge of a lead's (problem) situation, of goods and services offered by the vendor and its partners, and of how certain bundles of goods and services may be used for problem solving; we term this design knowledge. But especially external salespersons are not directly involved in product development at the employing vendor, and thus may have narrow insights on how their work affects downstream processes. Experiences from other salespersons may not be considered due to limited reporting or inconsequent knowledge reuse. And limited possibilities or rigid policies for inter-organizational communication may exclude design insights from partnering organizations. To overcome these shortcomings in intra-and inter-organizational design knowledge reuse, we've implemented a shared design knowledge repository based on the Function-Behavior-Structure (FBS) framework [4] and use it for services which support the design activities during lead qualification.

Xue and Xu [8] suggest a web-accessible distributed database to store design knowledge based on the FBS notation. Like other models that operationalize the FBS framework [2,6], they follow an entity-relationship approach. However, it would require a significant knowledge engineering effort to continuously maintain a design model that builds on a highly detailed and formal knowledge representation (KR), where innovative yet uncertain design beliefs may be left out. Probability theory can provide an adequate framework to model uncertainties in design decisions [5]. Encouraging approaches that represent probabilistic belief networks by means of semantic models exist in other domains [9,10]. But to the author's knowledge, there exist no Semantic Web representations of the FBS framework that incorporate uncertainty information, and can be managed in a multi-tenant environment. In [3] we defined a Bayesian Network (BN) representation of the FBS model, termed FBS-BN, which encodes design knowledge as probability tables. In the following we outline its shared storage in a distributed RDF-Store.

Design Knowledge Representation and Storage

A FBS-BN represents a configurational design space for a specific problemsolving situation in form of a Bayesian Network. Discrete random variables are used to describe possible design object configurations in light of the customer's demands. Every variable is associated with a certain component of the design object to serve as characterizing attribute. There are three different variable types: Function variables (F ) represent the purpose for which a solution is designed for, i.e. goals and constraints of the customer. Structure variables (S) represent possible offerings, i.e. product and service bundles that can be provided by the vendor. Behaviors are mediating concepts between Functions and Structures representing the actual solution, i.e. how products and services are meant to achieve goals and fulfill constraints. There are three subtypes of Behavior variables: Be variables describe the solution as expected by the customer; their value is derived from Function variables. Bs variables represent the solution as offered by the vendor; their value is derived from Structure variables. And Bc variables are used for comparing the match of Be and Bs. The design knowledge about how Functions, Behaviors and Structures affect each other is encoded in form of conditional probability distributions (CPDs). These CPDs represent a set of propositions of the form "if concept X is in state x then another concept Y is (or should be) in state y". The associated probabilities express the degree of belief that a proposition holds. Possible relations are F → Be (Function expects Behavior), S → Bs (Structure exhibits Behavior), and implications within a variable group (F → F , Be → Be, Bs → Bs, and S → S).

To support the assessment of information in lead qualification, a support service should highlight those concepts that are yet uncertain and thus need further investigation. Therefore we generate a case-specific FBS-BN to characterize the current problem-solving situation. Changes in a node's prior can be used to represent explicit design decisions (evidence), i.e. assigning a relatively high probability to a state would express its preference over other states. Implicit design decisions are then given by Bayesian inference in form of probability estimates for the hidden nodes. Building on this, we highlight (yet) uncertain concepts by rating every hidden node with an uncertainty measure (e.g. [3]). For using FBS-BN representations across different participating organizations, we employ a RDF-based shared design KR to store the needed variable, CPD, and design object component definitions. All applications interoperate via this KR. Principally we consider two types of client-side application roles, namely knowledge engineering and knowledge reuse applications. While knowledge engineering applications provide an interface to manage the KR, knowledge reuse applications use it to support designing tasks in problem solving situations (cf. Fig. 1). The KR is stored in a distributed RDF-store is based on S3DB [1]. S3DB provides a sophisticated framework for graph-based permission management. Rather than using coarse all or nothing policies, S3DB allows an organization, department or individual to share certain parts of their design knowledge with designated users. Moreover, S3DB offers a meta-model for cooperatively defining TBoxes and ABoxes for RDF-graphs.

To facilitate the hierarchical formalization of design knowledge on different levels of complexity we employ a formalism for iterative reification: We start from a simple relational model for design object component classes and their individuals. Component classes can be linked with "canBeRelatedTo" relations to denote that they are dependent "somehow". These relations then frame possibilities for "isRelatedTo" relations on instance layer. The first step in clarifying these yet anonymous relations is done by providing FBS-concepts as characterizing attributes for component classes and connect them via expects, exhibits and implicates relations (FBS-relations). These associations determine how the design object components are actually interrelated with each other. In the second step, FBS-concepts are operationalized as discrete variables by specifying a set of possible variable states (or attribute values), which results in a description of the attribute network as configurational variable space. Building on these variables we reificate attribute associations, i.e. we provide a detailed explication of expects, exhibits and implicates relations in form of conditional probability tables. Lastly variable and CPD definitions can be used as templates for FBS-BN instantiation.

Conclusion and Future Work

We have outlined a Semantic Web KR of the FBS framework based on RDF, which can be managed in a distributed multi-tenant environment. It is used to employ FBS-BN-based uncertainty reasoning for lead qualification support. Currently we are implementing two prototype applications, and look forward to test their impact on lead qualification performance empirically.