Producer

Conceptual design is concerned mainly with revealing the principle economical and technical foundations, on which to base any further elaboration of the design solution envisaged. Within the wider design problem-solving and decision-making framework, finding a general-purpose multi-criteria resolution of two closely intertwined problems – Consumer and Producer Choice – seems fundamental.

The Consumer Choice Problem: A Consumer has to choose from a range of similar products on the market. Different classes of those products exist as they are targeted at different groups of customers (sections of the market). This market partitioning is based on the realisation (on part of the manufacturers) that there exist different sets of unconditional requirements, which those groups of customers observe (consciously or not) - a kind of restrictions (limits) such as not buying above certain price tag or under set quality (e.g., brands, materials, etc.). Each particular customer, however, can have his own specific set of such constraints. In addition, he might have a further set of preferences (conditional requirements), each one of them having different degree of importance to him. Therefore, he may not necessarily fit exactly the existing market segmentation (fall into any of the general marketing groups) and would have to make some sort of compromise with respect to (trade-off between) different product characteristics in order to match his own preferences (criteria of choice) as close as possible while not exceeding his limits (refer to Basic Theory of Consumer Choice).

Note that constraints and preferences, whether inherent (e.g., weight) or utility based (e.g., warranty), may be overlapping (e.g., price used as a restriction as well as an optimization criteria of choice) and may be given either explicitly or derived from others. Note also that this task could be arbitrary complex (e.g., the so-called Consumer may be a company, looking for components to use in its own family of products).

The Producer Choice Problem: A Producer (e.g., an individual or a discrete manufacturing company) has to decide what kind of product (or rather a family of products) to launch on the existing market, described above, in order to gain access to a certain share of those consumers. In order to maximise his chances for a competitive advantage over other producers/suppliers, the potential Producer has to analyse the existing products (or selected prototypes) of his competitors with regard to their technical and user characteristics (e.g., functionality, price, etc.) as well as their targeted market segments (based on averaged consumer unconditional requirements) and current market share in each of them.

Based on such analysis, he has to devise one product or a set (family) of complementary products, which to constitute the main goal of his corresponding future business effort. However, the potential Producer has first to assess his own technical capabilities and compare them with those of his competitors in terms of (theirs and his own hypothetical) product properties as unique selling points, which would give him the necessary competitive advantage. If the Producer is to assess the situation from a Consumer's point of view, then the Producer choice problem may be considered merely as an augmentation of the Consumer choice problem with the potential Producer's hypothetical product(s) just added to the existing alternatives currently on the market. A further virtualization of the market place can be modelled by including only range prototypes rather than actually existing individual products.

Bearing in mind that nowadays in most industries the time-to-market requirements, on one hand, and degree of standardisation, on the other, are high enough to justify buying components rather than developing them from scratch, the potential Producer’s task largely may be reduced to mere product configuration and assembly. However, this would require detail assessment of components compatibility, reliability and other characteristics as well as terms of supply, quality guaranties and further maintenance. Ultimately, multiple system- and component-level alternatives should be considered with this regard by altering both properties and configuration(s) of the potential product(s) and evaluating (through a kind of 'what-if-analysis') the overall effects on this virtual market. Therefore, although the product configuration problem is a common place, its solution (and especially the decision-making process behind it) may well be extraordinarily complex, requiring sophisticated methods and tools.

The iConceptStore^™ based Solution: The iConceptStore^™ CML provides for describing each possible (existing or hypothetical) product alternative as a whole in terms of any number of common and/or unique (non shared) characteristics. Most of those attributes can be taken from the usual nomenclature used in descriptions of product features found on websites and shop labels as well as in product user manuals, if any.

In addition to this system-level predominantly quantitative description, each product alternative may be described in CML qualitatively as a multi-level structure of multiple inter-related components. In turn, each component (a product itself) may be described in similar terms as either primitive (part) or compound (system or assembly) and this distinction may change dynamically, depending on whether it can be supplied or is to be made/built/composed.

Ultimately, in order to allow for integral evaluation of each product alternative as a whole, selected system- and component-level properties of the product can be described quantitatively as depending on both quantitative and qualitative (e.g., structural) characteristics. A simple example of such multi-level (indirect) dependency would be the product price as a function of the prices of its primitive components and the production costs, related to their assembly.

The multi-criteria user choice is modelled by means of two important CML Library operations – Filter and Optimum. These very flexible routines are implemented as ordinary EntityNet server-side extensions and any custom routines of similar functionality can easily be substituted for them. Note that the CML Library built-in routines provide for CML-based declarative object-oriented programming capabilities within the iConceptStore^™ ResourceViewer event-driven visualization/execution environment and the underlying back-end EntityNet dynamic run-time functionality as well as standard front-end modelling tools such as MS Excel.

As the name suggests, the Filter operation (e.g., used to define the AcceptableAlternatives attribute) provides for discarding any possible alternatives (e.g., values of the PossibleAlternatives attribute), which do not satisfy the current restrictions (limits imposed on their attribute values). The input set of possible alternatives (list of entity names) may be either given explicitly as static values or generated by means of any custom-defined routine, attached to the PossibleAlternatives attribute. Likewise, the set (conjunction) of current CML constraint expressions may be given as static value of any entity attribute of class Constraint or generated by any custom-defined routine. Alternatively, they may be provided at run-time by means of dynamic CML parameters.

Accordingly, the Optimum operation (e.g., used to define the OptimumAlternative attribute) provides for imposing further (conditional) requirements on the result (set of acceptable alternatives), returned by Filter as values of the AcceptableAlternatives attribute. A multi-criteria selection is applied by evaluating and comparing acceptable alternatives in terms of any number of scalar criteria (selected product attributes), seamlessly automatically aggregated as an integral optimization criterion in accordance with the respective target Extreme (i.e., Minimum or Maximum) and Weight (relative importance) of each individual scalar Criterion, used in this vector optimization to yield the ultimate OptimumAlternative value(s).

For added flexibility of the modelling scenario, the relevant scalar criteria information may be given statically (as explicit entity attribute values) or provided dynamically at run-time - either generated by custom-defined routines or in the form of dynamic CML parameters (<Criterion, Extreme, Weight> triples) as part of any value retrieval request (by default, equal criteria weights are assumed). Note that using Filter output as direct input to Optimum provides for implicit constraint propagation by effect (any alteration to the CML constraint expressions results in changing the very foundation, hence outcome, of the optimization process).

Attribute evaluations (value retrieval requests) can be triggered either programmatically (from within EntityNet clients or extensions) or interactively (using iConceptStore^™ interactive utilities) or by means of embedded MS Excel links, updated either automatically or manually.

Apart from being easy-to-use, the latter option offers a standard front-end environment for performing different kinds of 'what-if-analysis' by embedding entity attribute value retrieval requests in the form of automatically updated advise links (interactively created and switched on/off at run-time by means of the iConceptStore^™ Excel Add-in). Such links designate selected entity attributes as being actively updatable whenever values of their dependency attributes change. In particular, since PossibleAlternatives is a direct dependency of AcceptableAlternatives, any update to the former would be immediately propagated to the latter. In turn, this would trigger an update to OptimumAlternative (as a direct dependant of AcceptableAlternatives, hence, indirect dependant of PossibleAlternatives). This kind of event chaining allows to keep complex inter-dependencies in synch and is the foundation of any advise link established. Coupled with embedded run-time value synchronization requests (e.g., replacing a component or changing values of its attributes or altering entire entity structure or passing variety of alternatives, restrictions and criteria as parameters to Filter and Optimum), this mechanism turns the iConceptStore-Excel modelling environment into a dynamic platform for carrying out a kind of "mental experiments" in order to gain insight for making informed decisions. Relevant task examples are: (1) to determine potential product configuration and properties, given certain market conditions (Consumer's limits and/or preferences); (2) to reveal the particular market conditions under which certain product alternative would prevail, if successful at all.

Note that this product solution-selecting scheme is quite generic. Only the CML descriptions of possible (existing and/or hypothetical) alternatives as well as relevant restrictions and optimal criteria specifications are problem domain specific. The decision-making framework itself is easily applicable to any problem domain (any instantiation of the general Consumer/Producer Choice Problem described). This allows to use the general-purpose parts of this solution as a Product Selection Shell. Any problem domain specific knowledge can be described by means of the iConceptStore^™ CML in domain specific terms (possibly in part provided dynamically at run-time) and thus immediately integrated within the decision-making framework outlined.

Such an approach enables designers and manufacturers, utilising this iConceptStore^™ based back-end solution from within a popular general-purpose front-end modelling tool such as MS Excel, to proactively reveal and assess their potential market position in terms of consumer choice criteria and accordingly choose the appropriate product configuration, related components and their properties long before actually producing and launching any product into the corresponding target segment of the market place.