GB2380000A

GB2380000A - Modelling product sales relationships in a retail outlet or shop

Info

Publication number: GB2380000A
Application number: GB0114557A
Authority: GB
Inventors: Dorota Malinowska; Madan Gopal Singh; Jean-Christophe Bennavail; Evdokia Borissova Krasteva
Original assignee: Knowledge Support Systems Ltd
Current assignee: Knowledge Support Systems Ltd
Priority date: 2001-06-14
Filing date: 2001-06-14
Publication date: 2003-03-26
Also published as: GB0114557D0

Abstract

A method for modelling relationships between a plurality of products sold by a retail outlet. Each product to be modelled is allocated to a category, such that a model is created containing a plurality of categories each containing a plurality of products. At least one product in each category is nominated to be a category flag product, and relationships between products within the same category are modelled. Relationships between two products allocated to different categories are modelled only if the two products are both category flag products.

Description

MODELLING METHOD The present invention relates to a method and apparatus for modelling relationships between a plurality of products sold by a retail outlet, and more particularly to such a method that may be used to aid pricing decisions in a large-scale retail outlet selling for example tens of thousands of products.

In the highly competitive mass retail market, pricing is of crucial importance to managers. The classical cost based and competitor based pricing approaches have in recent years been supplemented with techniques based upon mathematical models.

Such models provide means to quantify the effect of pricing decisions, allowing managers to reach optimal decisions with respect to specified criteria. Many of these models work well for small scale retailing but applying the same models to mass retailing, where tens of thousands of products need to be priced, is not viable due to the sheer size of the problem to be solved.

Even a simple pricing model for a large retail outlet will need to include tens of thousands of variables representing prices of products sold by the retail outlet.

Additionally, it will be necessary to store parameters reflecting the impact of price changes upon the demand for the various products as well as their effect upon chosen performance measures.

The use of mathematical models in mass retailing therefore creates two processes that are affected by model size. First, having determined which products may affect the sales of a predetermined product, it is necessary to quantify these relationships by tuning the system using historical data. This process is known as parameterisation.

The larger the number of relationships the more acute the problem. Second, it is necessary to take the parameterised demand model and calculate optimum prices. The greater the number of price variables, the greater the model complexity and therefore the harder the optimisation process is to undertake.

Parameterisation in the case of a large number of parameters requires a large quantity of data in order to obtain a satisfactory approximation. This data can come from a number of sources, including historical data, market research data, price experiments, managerial expertise, and non-price product attributes.

Historical data comprising prices, sales and profits is gathered regularly as a matter of routine. However, in order to be useful for model calibration, this data must include at least one price change and the resultant effect upon the model output. Given that product prices in large retail outlets do not change frequently, it is difficult to gather

sufficient data to allow estimation of a very large number of parameters. z Market research data is expensive to gather and must be interpreted with caution. In its analysis, researchers must consider behavioural aspects of consumers and must realise that the data obtained will not represent the opinions of"rational"buyers in the sense of decision theory. The analysis of this data is particularly complicated when the number of parameters is very large. In addition to the high level of noise, this data is more useful for establishing long term trends than for optimising a pricing strategy on a day to day basis, taking into account the numerous interrelationships between individual product prices. Different methods of collecting data representing the effects of price on consumer behaviour are summarised in Price, Simon H :"Management", North Holland 1989, Page 26 table 2.4.

Data obtained from price experiments is far less noisy, and can be accumulated more quickly than historical data. The drawback here however, is that price experiments are not always feasible to perform. Again the greater the number of parameters that are to be estimated the longer and more expensive the experiments become.

Pricing estimates made by managers are relatively cheap to obtain and are also a reasonably reliable guide. However getting enough data to calibrate a very large model is an overwhelming task, because it is very difficult for a human being to judge

the effect of more than two or three price changes that are effected simultaneously when considering a price in question.

Non-price product attribute data is routinely stored by mass retailers, but the effect of such data on the parameters of a demand model is less direct and more complicated to estimate, especially in the case of a large number of products.

From the above description it will be clear that the main problem to be solved in calibrating a model through parameterisation is reducing the amount of data necessary to accomplish the calibration. This problem is the same regardless of the source of information used.

Price optimisation poses another size related problem, as again a very large number of variables are involved. Solving any optimisation problem with 30, 000 to 50,000 variables within standard processing power and managerial time limits has not yet been achieved using widely available computer power.

From the above, the obvious solution would seem to be to reduce the size of the problem, in terms of the number of price variables and model parameters. However, in common with any modelling problem, there is a trade off between simplifying the model and the usefulness of the data that is obtained. A model that is too complicated is too difficult to maintain and evaluate, whereas a model which is over simplified will not reflect the reality of the modelled situation with desired precision.

Considerable work has been undertaken into investigating the effects of price changes on demand in retailing, but this work either involves a small number of products or refers to brands or to product categories as a whole (see for example Hoch S. J., Kim B. D., Montgomery A. L. , and Rossi P. E :"Determinants of store-level price elasticity" Journal of Marketing Research, 1995 volume 32, pages 17-29). While the pooling and

aggregation of several products into a single composite product in this way may be I ZD useful for high level management purposes, it is not sufficient to support low level pricing decisions (see for example Montgomery A. L. , Rossi P. E. ;"Estimating price

elasticities with theory based priors"Journal of Marketing Research, 1999, volume 36, pages. 413-423). When historical data is used as a source of calibrating demand models, it is also beneficial to bring in additional non-price information (as described by Montgomery and Rossi).

Many large-scale retail outlets group their products into a hierarchy including for instance departments, categories and sub-categories for management, pricing and reporting purposes. Such classifications may also be of use for space allocation and assortment planning. (For more information see for example Rajarman K: "Assortment Planning in Fashion Retailing : Methodology, Application and Analysis" European Journal of Operations Research, 2001, volume 129 pages 186-201).

Hierarchical grouping of products for example on the basis of categories and subcategories is widely applied in retail outlets. Such a structure provides a starting point for designing a demand model for a retail outlet. However, the structure itself is not enough to enable the design of a useful simplified model. It does not provide any links between the levels of store, category and subcategory. It only links lower level elements (e. g. products) into higher level elements (e. g. subcategories). Utilising only such links does not lead away from a"flat"demand model and the necessity to optimise a very large model.

Therefore while a model involving a hierarchical grouping of products such as categories and subcategories is of some use, the problems of model size described above are not solved satisfactorily unless the number of parameters in the model is reduced.

It is an object of the present invention to obviate or mitigate the problem outlined above to provide a generally applicable method of pricing that may be used in large scale retail outlets.

According to a first aspect of the present invention there is provided a method for modelling relationships between a plurality of products sold by a retail outlet, wherein

each product to be modelled is allocated to a category, such that a model is created containing a plurality of categories each containing a plurality of products, at least one product in each category is nominated to be a category flag product, relationships between products within the same category are modelled, and relationships between two products allocated to different categories are modelled only if the two products are both category flag products.

The term category flag product is used herein to mean a product nominated as having an influence on customer perception of the category to which it belongs. Generally a category flag product will be a main driver of the category's performance.

Preferably, any product not nominated to be a category flag product, is modelled to have relationships only with category flag products. The relationships to be modelled may represent cross elasticity.

At least one product sold by a competitor of the retail outlet may also be modelled.

Preferably a product sold by a competitor is modelled only if it corresponds to a category flag product. Relationships between the product sold by the competitor and products sold by the modelled retail outlet may be modelled only in the case of category flag products.

Preferably, the retail outlet is modelled in an hierarchical manner, whereby each category is modelled to contain at least one subcategory, and a product allocated to a predetermined category is allocated to a subcategory contained within said predetermined category. Preferably, at least one product in each subcategory is nominated to be a subcategory flag product.

The term subcategory flag product is used herein to mean a product nominated as having an influence on customer perception of the subcategory to which it belongs, and generally will be a main driver of the subcategory's performance.

Preferably, a product not nominated to be a subcategory flag product is modelled to have relationships only with products in the same subcategory and more preferably to have relationships only with subcategory flag products. Preferably, a relationship between a first product allocated to a first subcategory of a first category, and a second product allocated to a second subcategory of the first category is modelled

only if said first product and said second product are both subcategory flag products. z : l Z-1 A category flag product may be modelled to also be a subcategory flag product.

According to a second aspect of the present invention, there is provided a method for modelling relationships between a plurality of products sold by a group of retail outlets, wherein each retail outlet is modelled using a method as described above, and relationships between at least one pair of category flag products in different retail outlets are modelled.

At least one modelled product may be an aggregation of a plurality of products sold

by the retail outlet, and the aggregation may be performed by a computer, using tn predetermined criteria such as brand, price, size, and packaging type, customer type, cost or usage.

According to a third aspect of the present invention, there is provided a method of determining an optimum set of prices for a plurality of products sold by a retail outlet, comprising modelling relationships between said plurality of products using a method as defined above, using the modelled relationships to create a demand model of predetermined form, determining parameters for said demand model to generate a parameterised demand model, and using said parameterised demand model to determine a set of prices which yields an optimum value for a predetermined optimisation criterion.

Preferably, the parameterisation is carried out using a mathematical best fit approach to fit the demand model of predetermined form to a set of historical data.

Parameterisation may be carried out in a top down manner such that parameter values associated with category flag products are calculated before parameter values associated with subcategory flag products.

Parameterisation may be carried out in a top down manner such that parameter values associated with category flag products and parameter values associated with subcategory flag products are calculated before parameter values associated with other products. Parameter values associated with products nominated by each retail outlet may be calculated before parameter values associated with category flag products.

Preferably, optimisation is carried out in a top down manner such that optimum price values associated with category flag products are calculated before optimum price values associated with subcategory flag products. The price of each category flag product may be calculated prior to the calculation of an optimum price for any subcategory flag product. Optimisation may be carried out in a top down manner such that optimum prices for category flag products and optimum prices for subcategory flag products are calculated before optimum price values for other products. The predetermined optimisation criterion may be profit.

Optimum prices may be subject to one or more constraints. For example, prices of a product may be constrained with reference to: the price of another product sold by the retail outlet, and/or cost of the product, and/or a previous price of the product, and/or a price of a product sold by a competitor and/or a predetermined price point of the product.

The model of the retail outlet may be held in a database and the database may be implemented using Structured Query Language.

Preferably, the method as described above is implemented by a computer. The method may be carried out on a plurality of computers, each computer connected to a computer network.

According to a fourth aspect of the present invention, there is provided a computer readable file storing a plurality of records, each record comprising data relating to a product sold by a retail outlet, wherein each record comprises a product identifier and an identifier of a category with which the product is associated, and the file further comprises an indication of at least one product in each category that is nominated as a category flag product. Preferably, each record includes a field for storing data indicating if the product is a category flag product.

Each record may further comprise an identifier of a subcategory with which the product is associated and an indication of at least one product that is nominated as a subcategory flag product.

The file may further include at least one competitor product record, the or each competitor product record representing information about a product sold by a competitor, and each competitor product record comprising a product identifier.

According to a fifth aspect of the present invention, there is provided a computer program element comprising computer program code means for creating a model of a retail outlet comprising a parser for reading a computer readable file as defined above.

The term parser is used herein to mean a device for parsing. Parsing is a well known term in the art being the process of reading a string of input symbols and determining its validity, validly read symbols are then interpreted to give meaning to the input data using rules defined within the parser.

According to a sixth aspect of the present invention, there is provided a computer program element comprising computer program code means for carrying out a method as described above.

According to a seventh aspect of the present invention, there is provided a carrier medium carrying computer readable code for controlling a computer to carry out

procedure according to the method as described above. The carrier may be a CDROM or a communications line.

The term carrier medium is used herein to mean any medium that may carry computer readable data. This includes a communications line, a computer network such as the Internet, or tangible carrier media such as discs and compact discs.

According to an eighth aspect of the present invention, there is provided a server comprising a connection to a computer network and means for remote access from a remote computer connected to the computer network, wherein the server stores a computer program element as described above and allows a user to access said computer program element.

According to a ninth aspect of the present invention, there is provided an apparatus allowing a user to access or manipulate a model created using a method as described above, comprising output means for displaying the model to a user, user interaction means for allowing a user to select or edit part of the model, processing means responsive to said user interaction means for manipulating the model, and computer program code means for controlling said processing means. The apparatus may further comprise non-volatile data storage means for storing the model.

The term non-volatile data storage device is used herein to mean a device capable of storing data when power is removed. Examples of non-volatile storage devices include hard disk drives, floppy disk drives and Compact Disc Read Only Memory (CD-ROM).

According to a tenth aspect of the present invention, there is provided an apparatus comprising a non-volatile storage medium, the medium having thereon a model created using a method as described above.

According to an eleventh aspect of the present invention, there is provided an apparatus for carrying out a method according as described above.

An embodiment of the present invention will now be described, by way of example, with reference to the accompanying drawings, in which: Figure I is a flowchart showing an overview of a price decision process according to the present invention;

Figure 2 is 8 flowchart showing the processes occurring within step 1 of the zn flow chart of Figure I in more detail; Figure 3 is a schematic illustration of an aggregation process that may occur in an embodiment of the present invention; Figure 4 is a schematic illustration of a mass retail outlet where products have been allocated to categories and subcategories ; Figure 5 is a tree diagram showing how products are classified into categories and subcategories within a store (also referred to as a retail outlet) model; Figure 6 is a schematic illustration of how relationships between products

within the various categories and subcategories of figure 4 are modelled according to zn the present invention; Figure 7 is a graph showing how a system embodying the invention may be tuned using historical sales data;

Figure 8 is a flowchart showing processes occurring within step 3 of the 17, flowchart of Figure 1 in more detail ;

Figure 9 is a graph showing the effect of strategic constraints upon possible price values ; Figure 10 is a schematic illustration of a computer system on which an embodiment of the present invention may be executed; Figure 11 is a schematic illustration of three modules and their interrelationships within a system embodying the present invention; Figure 12 is a data flow diagram showing the interrelationships between software components within a system embodying the present invention; Figure 13 is an illustration of a format for a data file that may be used to input product information into a system embodying the invention; Figure 14 is a screen dump of a computer terminal display in which a user may input price positioning constraints which are used in an embodiment of the invention; Figure 15 is a screen dump of a computer terminal display in which a user may input price fluctuation constraints which are used in an embodiment of the invention; and Figure 16 is a screen dump of a computer terminal display in which a user may input cost data and sales and price constraints which are used in an embodiment of the invention.

Referring first to figure 1, an overview of steps undertaken by a computer t : l implemented pricing decision support system according to the present invention will be described. A more detailed description of each step will be presented below.

The system aims to provide a set of product prices which will allow a particular performance measure to be optimised. One such performance measure that is frequently used is overall profit.

First, a model of a store in which pricing decisions are to be made is created (step 1).

Input to step I will include details of categories (for example fresh fruit) and subcategories (for example bananas) within the store, and also details of the products in the store and the categories and subcategories to which they belong. This input information is used to generate all product interrelationships that exist within the store.

At step 2, product interrelationships of the store model created by step 1 are quantified into a mathematical demand model. That is, step 1 will determine a set of products whose pricing will affect the sales of a particular product being considered.

In order to take the pricing process forward these effects must be quantified and this is carried out by step 2. This is achieved by taking the interrelationships and fitting them to historical data to obtain an accurate demand model. This process is described more fully below.

Managers may wish to impose constraints on price of a particular product. For example, it may be desirable to limit price fluctuation, or to set upper and lower bounds for possible price values. Such constraints are specified at step 3, and validated to ensure that they are both reasonable and non-contradictory at step 4.

It will often be the case that the performance measure that is to be optimised is profit.

In order to calculate profit, it is clearly necessary to know the cost of the item and any overheads associated with it. This information is input at step 5.

When the model has been created (step 1) and its relationships quantified (step 2), any constraints have been added and validated (steps 3 and 4), and costs have been taken into account (step 5), the model can then be optimised to yield an optimum set of prices with regard to some optimisation criterion (step 6).

Each of the steps of the flowchart of figure 1 will now be described in more detail.

Referring now to figure 2, the processes of step 1 of figure 1 are shown in greater detail. First, the categories within the store are defined and form data input to the system at step 1.2. Standard computer input mechanisms such as reading input files stored on a carrier medium or interactive input may be used. This input will be performed by a manager of the store and such information should be readily available from standard analysis techniques. Categories will equate to departments in the store. For example one category may be fresh fruit, another may be soft drinks and another may be wines.

A subcategory will equate approximately to a shelf, collection of shelves, or section within a department, and within the fresh fruit category for example, sub categories will include apples, oranges and bananas. These subcategories will be input into the system at step 1.3 in a similar way using conventional input means, each subcategory including details of its"parent"category. Products also need to be input into the

system in a similar way, along with information about the subcategory and category to t : l which they belong.

The products are then assessed with respect to key attributes which determine whether or not they are identical for pricing purposes. Such attributes include type, brand, packaging, costs, customer type and usage. Products that are found to be equal in respect of all these attributes are combined to form a single aggregated product. This has the effect of reducing the number of products that need to be represented in the model. This occurs at step 1.4 of figure 2.

Referring now to figure 3, an example of the aggregation process is shown. Suitable candidate products for aggregation may be various flavours of the same product, in this case potato crisps. Here, product 1 (cheese and onion flavour crisps) and product 2 (salt and vinegar flavour crisps) are both aggregated with ready salted flavour crisps. Practically, this means that the price of all three products will be the same.

Aggregation decisions can either be performed manually, or by providing attribute values to a simple computer program which can then automatically decide whether or not products should be aggregated.

When category, subcategory and product information has been input into the system and any product aggregation has taken place, each product (including aggregated products) is allocated to a subcategory (step 1.5) which is specified by a user using interactive or file based input. Each product belongs to exactly one subcategory, and each subcategory belongs to exactly one category.

Products sold by competitor retail outlets are also input to the system in a similar way

if they are to influence pricing decisions. Such key competitor products are defined at . Y Lo I 1 1 1 3 step 1. 8. A form for the demand model may be determined at step 1. 9, although in a tD preferred embodiment of the present invention the form of demand model is predetermined.

A representation of the store will then be held by the computer and this is schematically illustrated in figure 4. Here, a retail outlet represented by 1 contains a first category 2 containing two subcategories 2A and 2B and a second category 3 contains three subcategories 3A, 3B and 3C. All five subcategories are populated with products, schematically represented by small light grey disks.

Hierarchical relationships between products and their sub-categories and categories as shown in figure 4 are illustrated by a tree diagram in figure 5. Here leaves of the tree are products sold by the store, each product being assigned to one subcategory which is its parent. Each node representing a subcategory is itself a child of a further node representing a category. A node at the highest, or root, level of the tree represents the store, and all categories are children of this store node.

It will be appreciated that a company operating a number of large scale retail outlets such as a supermarket chain, will be able to employ the model with an extra layer, that is each store node of figure 4 will be a child of a group node. This situation may occur

when a company decides to price a product at different prices in different stores within its group. A collection of stores represented in this way is often known as a segment. If a company decides to price a product at the same price in all stores within a segment, the segment can be represented as one aggregated store.

The use of a hierarchical grouping system based upon categories and subcategories has the advantage that such a grouping is traditionally used in large scale retail outlets for managerial purposes, thus adding much more meaning to the model from the point of view of a manager. This structure provides a starting point to structure and simplify a demand model. Although aggregation as described in step 1.4 will reduce the number of pricing variables, further improvements are necessary to create an optimisation problem which is easier to solve.

The necessary improvements are achieved by the present invention's use of category and subcategory flag products. (steps 1.6 and 1.7) A flag product is defined to be one which influences customer perception of its category or its subcategory, and is a main driver of its category's or subcategory's performance. At least one flag product is nominated for each category and subcategory of the store structure. A product can therefore be the flag for its category and/or subcategory. A product that is a flag for its category is always considered to be a flag of its subcategory. Each subcategory and category may contain more than one flag product. In accordance with the invention, relationships between two products allocated to different categories are modelled only if those two products are category flag products.

Limiting inter-category product relationship modelling to category flag products 1= Z=l radically reduces the size and complexity of any demand model of the store and yet results in a useful model because category flag products are, by definition, main sales and revenue drivers and therefore exercise the strongest influence on sales of other, non-flag products.

In all forms of demand model, the sales of each product depend on its own price and on the prices of other products related to it. In theory, the price of any product in the

store can influence the sales of any other product. However, not all these relationships are of equal influence and many are so weak that their influence can be considered to be negligible.

Significant relationships are those with other products of the same subcategory, (for example sales of a particular variety of apple are more likely to be affected by prices of other apple varieties than the price of fresh meat products). Relationships with the flag products for the subcategory are particularly significant.

Significant relationships with products from other subcategories and other categories are either weak enough to be negligible or are confined to the corresponding flag products.

These considerations of product interrelationships define the rules that determine which relationships should be included in the demand model and which relationships may be excluded. The strong relationships are those between two flag products, or between a flag product and a non-flag product within a single category or subcategory. The weak relationships are those between two non-flag products. These are excluded from the demand model as they add great complexity to the model while having minimal influence on pricing.

It will be appreciated that any pricing strategy must also take a store's competitors into account and this will be described more fully below. Similar considerations apply to the relationships with competitor products. Only key competitor products, equivalent to the retail outlet's own category flag products, are considered (step 1.8).

The considerations outlined above lead to the formulation of rules which may be applied to determine the relationships that must be considered by any demand model.

These rules may be as follows: A non-flag product may have modelled relationships only with flag products for its subcategory.

A subcategory flag product may have modelled relationships with the following products: Category flag products from the same subcategory; Other subcategory flag products from the same subcategory ; and Non-flag products from the same subcategory.

A category flag product can have modelled relationships with the following products: Category flag products from the other categories; Category flag products from the other subcategories in the same category; Other category flag products from the same subcategory ; Subcategory flag products from the same subcategory; and Key competitor products (flag products for the corresponding category in a competitor store).

The relationships listed above are equally applicable to aggregated and non-

aggregated products. z These modelled relationships are illustrated in figure 6. Here small discs represent non-flag products, large light grey discs represent category flag products, dark grey discs of intermediate size represent subcategory flag products, and large black discs represent competitor products.

Referring to figure 6, line 4 connects a non-flag product to a subcategory flag product, representing a modelled relationship between a subcategory flag and a non-flag product within subcategory 3C. Line 5 connects a category flag product to a subcategory flag product and represents a modelled a relationship between a category flag product and a subcategory flag product within subcategory 2B. Line 6 connects two subcategory flag products and represents a modelled a relationship between two subcategory flag products within subcategory 3B. Relationships between categories are modelled only between category flag products and this is represented by line 7 linking a category flag product in category 2 and a category flag product in category

3. Relationships can also be modelled between category flag products in the same I tn category, and this is shown by line 8, representing a modelled relationship between two category flag products, a first product in subcategory 2A and a second product in subcategory 2B. Line 9, connecting two category flag products, again represents a modelled relationship between two category flag products, but this time within a single subcategory 3A. Relationships with competitor products are modelled only with category flag products and this is represented by line 10 linking a category flag

product in subcategory 2A to a competitor product. n The relationships specified by the rules given above therefore greatly reduce the number of products whose price must be considered when choosing a price for a predetermined product. This reduces the size of the demand model and therefore makes the problem of its parameterisation and optimisation soluble. This is achieved because the vast majority of the products in a store will be non-flag products, and a non-flag product will have modelled relationships only with the or each subcategory flag product of its subcategory.

Referring once again to figure 1, the processes of step 2 will now be described in

more detail. For a predetermined product, step 1 will determine a set of products that will affect sales of the predetermined product, and the form of the demand model. Step 2 takes the general form of the demand model and creates a specific demand model in which these relationships are quantified. The general form of this demand model will be:

where S, represents sales of product i, f is a demand function chosen on the basis of analysis of price and sales data from the particular retail business area;

P, is a vector of prices of product i and of other products influencing the sales of product i ; Y, is a vector of parameters reflecting the influence of the prices in vector p, upon the sales of product z ; 7f, is a vector of parameters reflecting the influence of non-price marketing factors upon the sales of product i ; and f, is a vector of parameters reflecting the influence of price moves in past pricing periods upon the sales of product i.

In a preferred embodiment of the present invention the form of the demand function ! is predetermined for a particular product, although a different form of model may be used for different products within a retail outlet. For example, fast moving daily use items such as bread and milk may need to modelled differently to rarely bought luxury items such as fine wines.

P, will have been determined in step 1, and purpose of step 2 is therefore to determine a value vector 7" Parameters within 7, are the most important, since price is the most influential factor for the product sales. In many practical cases 77, and f, may be omitted from consideration.

A simple example of a demand model and determination ouf/, therein will now be presented. It will be appreciated that in a real commercial environment a more complex, non-linear, demand model may be used.

Referring again to figure 6, it will be seen that the sales of the non-flag product 11 will be influenced by the prices of category flag product 12 and subcategory flag product 13, in addition, of course, to its own price.

Therefore, in this case:

It is now necessary to determine how each of these parameters affect the sales in order to obtain parameters for the demand model. This is done by taking a set of historical data and fitting the demand model to this data using a best fit method to apply a curve to the historical data, thus determining values for the parameters of the/. The best-fit method will be chosen dependant upon the particular form of demand model being used, as will the shape of the curve. The process of determining r is hereinafter referred to as parameterisation.

Figure 7 shows a simple example of this process, wherein sales of a product are shown on the y-axis and price is shown on the x-axis. Thus sales are affected only by a single price variable in this case. Points are plotted representing known (price, sales) combinations (PI, s1), (P2, s2), (P 3, s3), (P4, s4). Each of these points will be representative of the price for product i over a given time period t with resulting sales St. In general terms, data for all members of vector 15, will be needed and therefore the reduction of the number of relationships that need be considered by the method of step 1 will simplify this parameterisation process.

A demand model represents the phenomenon known in the art as elasticity. In general terms, elasticity is a widely used measure of the impact of price on sales. Price elasticity of sales is a relation of relative change of sales of a first product, to a relative change of price of either the first product or a second product. If the price of the first product affects sales of that first product this is known as direct elasticity. If the price of the second product affects sales of the first product this is known as cross elasticity. Elasticity is described in more detail in Lilien G. L. and Kotler P: "Marketing Decision Making. A Model Building Approach", Harper and Row, 1983.

A line or curve of best-fit LI is then fitted to these points, and its equation calculated. The implementing software will have predetermined parameters to influence the shape of the curve. So, in the simple case of figure 7, the demand model has the form:

and the best fit process will use conventional mathematical means to determine a and b to give an equation for the best-fit line Ll. In this case, a and b will be the parameters y of the generalised demand model of equation (1).

In the example of equation 2, there are three price variables, and therefore a multidimensional graph will be plotted, and the curve fitted in this multi-dimensional space.

The reduction of the number of relationships by the use of flag products simplifies this parameterisation process considerably. The reduction of complexity means that less data is needed to carry out the parameterisation process.

Parameterisation is performed in a top down way across the product hierarchy. Store level parameterisation calculates the parameter values for the category flag products in each category. Category level parameterisation calculates the parameter values for the subcategory flag products in each subcategory of the category. Subcategory level parameterisation calculates the parameter values for the non-flag products from the subcategory. Only product relationships which comply with the rules defined above are maintained in order to reduce complexity of the resulting model and of the parameterisation process.

It will be appreciated that if the invention is applied to a segment of retail outlets, an extra segment level parameterisation step will be required.

The output of step 2 is values for/,. Therefore, since f and P, are known from step 1 of figure 1 a demand model having the general form given in equation (2) above has been created.

Referring back to figure I once again, step 3 comprises the imposition of strategic pricing constraints, to limit the possible price values for each product. The process of imposing such constraints will now be described with reference to figure 8. In the description that follows, the price of only one product is discussed. It will be appreciated that in practice it will be necessary to apply similar considerations to all products whose price is considered. It will be appreciated that strategic price constraints are not limited to those set out below.

Step 3 restricts the price between predetermined boui-ids and These bounds are composed from a number of different constraints that are outlined below.

Step 3. 2 specifies an upper bound and a lower boundp, o, r these are derived from product costs and general market considerations. For instance, a price should be higher than the total costs associated with the product.

It may also be desirable that the product price is allowed to fluctuate only within predetermined limits for customer expectation reasons. This is achieved at step 3. 3 and is determined by general market behaviour and results in imposing additional

price bounds/,,,,,,,, and ,,, , as follows :

where is a product's current price ; ,,,, is the absolute value of the downward limit on price movement ; and

Pis the absolute value of the upward limit on price movement.

Additional price positioning constraints define the relative price placement of the product with respect to other products sold by the retailer and to products sold by key

competitors. Setting price positioning constraints abides by rules identical to those for z : l setting model relationships discussed at step I above.

The price positioning constraints with competitor products are set at step 3. 4 and have the form:

where p is the price of the product currently being decided; K is the set of competitor products influencing the sales of the product; k is a member of set K; pu ils the price of product k ; pos is the desired minimum difference between the product price and that of product k ; and pos,',,, is the desired maximum difference between the product price and that of product k.

The price Pk is that of the competitor and is therefore known and cannot be changed, equation (6) can therefore be written as follows:

This therefore defines an additional upper and lower bound related to the position

with respect to each competitor product. The case wl-ien pos',,, = POSA, = 0 Ill in ix represents a strategy of matching the price of the competitor's product k.

A simple worked example of use of equation (7) will now be presented with respect to the following scenario : A major competitor charges 50 pence for a particular product A. As a matter of strategic policy it is desired that an outlet making pricing decisions is never more than 2 pence less than their competitor, but is also never more than 1 penny more than their competitor. For simplicity only one competitor product is considered to be of relevance.

Recalling equation (7):

The set K is a singleton set (containing only one product A). Therefore equation (7) becomes:

In this case:

pos,",,, =-2 (as it is required that prices may be up to 2 pence less than the n price of the competitor) ;

po, au = 1 ; and 11, PA = 50.

Substituting for the variables, equation 8 becomes :

Thus, price can be between 48 pence and 51 pence inclusive as we would expect. In general terms, the set K will not be a singleton set and therefore a number of equations to form upper and lower bounds will be formed for each k in the set K.

The strategic constraints described above are combined at step 3. 5 of figure 8 to form

an overall lower and upper limit ' and "' on the price of each product sold ll, Pei, by the retail outlet as follows.

where min () is a predefined function which returns the minimum value of its arguments and max () is a predefined function which returns the maximum value of its arguments.

Equation (10) therefore states that the overall lower bound will be the maximum of the following: The minimum price imposed in step 3. 1 ; The lower bound determined to limit fluctuation determined in step 3. 2; and The minimum price determined with reference to each competitor product k by equation (8) at step 3. 4.

The max () function will therefore haveK + 2 arguments, where IKI is used to denote the cardinality (i. e. the number of members) of set K as each product k will determine a minimum price bound.

The setting of the overall upper bound is analogous to this process, that is the overall upper bound will be the minimum of the following : The maximum price imposed in step 3. 1; The upper bound determined to limit fluctuation determined in step 3. 2 ; and

The maximum price determined with reference to each product k by equation (8).

The min () function will have IKI + 2 arguments as explained above.

It may also be desirable to specify a price point policy to which all products in a retail outlet should conform, and step 3. 6 imposes such constraints. The price points define the last digits of the prices. Price points can be set for a category, subcategory or individual product. They allow a retailer to exploit psychological characteristics of a buyer's decision making process. For example, a price of f1. 99 may be perceived as considerably lower than a price of 2-00. The basis of psychological pricing is described in Wedel M. and Leeflang P. S. H :"A model for the effects of psychological pricing in Gabor-Granger price studies"Journal of Economic Psychology 1998 volume 19, Issue 2, pages 237-260.

Price points set in this way transform the possible price values from a continuous into a discrete set, wherein all set members terminate at the required price point.

The final price constraint is dealt with by step 3. 7 and concerns price positioning constraints with respect to other own products. These have the same form as those with competitor products:

where Q is the set of other own products influencing the sales of the product, and other terms in the equation are analogous to those in equation (8).

The difference between equation (8) and equation (12) is that here both prices, p and Pk n can be changed whilst in equation (8) Pk represents a competitor's product price and is therefore fixed. Thus constraints according to equation (8), amalgamated with

constraints according to equations (4) and (5) and the basic upper and lower bound tn constraints, are treated independently of constraints according to equation (12).

In addition to constraints on price, it will be necessary to specify the desired volume of sales of each product. Sales bounds include a minimum and a maximum value for the sales of a product. They are calculated as a percentage of average sales history for the product. Defining sales bounds guarantees that prices are set in such a way as to ensure that realistic, desired and planned sales are achieved.

The imposition of these constraints is such that the range of the demand function is controlled. That is:

where is tl-te minimum value for desired sales; and

-S* is the maximum value for desired sales.

Referring now to figure 9, vertical line 14 towards the bottom of the price scale represents the value of p and the vertical line 15 having a higher p value represents Pupperoverall. The horizontal line 16 represents the minimum bound for sales values'S'/,,,,,,,,., while the horizontal line 17 represents the maximum bound for sales values Supper. Therefore, possible values for price are those on line LI (determined by step 2), within box 18, box 18 being framed by lines 14,15, 16 and 17. The

a'if c are not constraints specified by equation (12) will also be taken into account, but these are not illustrated in figure 9.

However, setting of price points in step 3. 6 of figure 8 means that only a discrete number of values 19 within the area of box 18 will be valid choices conforming with the price point policy.

Referring back to figure 1, completion of the price decision process will now be ZD described. Having specified a number of different constraints at step 3, it is necessary

to ensure that all constraints can be concurrently met and that the constraints are selfconsistent. All constraints have to be satisfied simultaneously, so before optimising it is necessary to ensure that there is at least one set of product prices satisfying all of the specified constraints of step 3. If this is not the case, the constraints need to be reviewed or otherwise it will not be possible to perform optimisation in a later stage of the process.

The demand model has a variety of managerial uses but ultimately the most important of them is its usage in an optimisation model. When pricing the products in a store the aim is to do so in such a way as to satisfy a set of objectives of the company. These objectives relate to performance, price, image, costs, sales, etc. , and each has a different importance attached to it. Usually the most important aim is to maximise the total profit of the store, so profit serves as an optimisation criterion, and the other aims are represented by constraints.

It will be appreciated the total profit for a retail outlet is given by the equation:

where (D is the set of all products sold by a retail outlet; p, is the price of a product I excluding purchase tax (e. g. Value Added Tax in the United Kingdom); i is a member of the set C ;

cost, is the cost of a product i ; sales, is the number of units of product i that are sold in a predetermined time period; profit, is the profit of a product i ; and profit is therefore the overall profit made within said predetermined time period.

It will therefore be appreciated that the cost of each product must be input to the system, in order to solve the optimisation equation. The costs for each product are composed of different elements specific to the category, subcategory, and the product itself. All costs that are to be taken into account when solving the optimisation equation are taken into account at this stage, including for example, overheads. Any purchase tax (e. g. Value Added Tax in the United Kingdom) is not taken into account when modelling costs. The purchase tax is subtracted from the retail price of a product i when calculating its profit, as shown in equation (14).

Having set cost information, the system now has the necessary information to find an optimum set of price values that will maximise the store's profit while satisfying all constraints specified by the user.

Optimisation is performed in a top-down manner across the product hierarchy. Store level optimisation determines the prices of the category flag products from all categories in the store. Category level optimisation determines the prices of all subcategory flag products from all subcategories in the category. At the same time, the prices of the category flag products are kept fixed at the values found during the store level optimisation. Subcategory level optimisation determines the prices of all

non-flag products from the subcategory. The prices of the subcategory flag products t : l zn are kept fixed at the values found during the category level optimisation. It will be appreciated that if the invention is applied to a segment of stores, an extra segment level optimisation step will be required.

The optimisation process outputs a set of prices that produce the optimum value for the criterion to be optimised (e. g. overall profit) having due regard to any constraints on price or sales specified in step 4 above.

Referring to figure 10, a conventional personal computer suitable for running an

application implementing the present invention is shown. The computer has a C > keyboard 20 for data input and a pointing device 21 which a user may operate to select items appearing in a graphical user interface (GUI) displayed on a display 22.

The computer additionally has a data storage device 23 which may conveniently be a non-volatile disk (commonly known as a hard disk). Applications are stored in a compiled form on the data storage device 23 and copied to a program memory 24 when they are to be executed. All the aforementioned components are connected together by a common bus 25. Program code is read from the data storage device 23 into a program memory 24, passing along the bus 25. For execution, instructions travel from the program memory 24 along the bus to a processor 26 where they are executed. In execution, the application is likely to require input data obtained from the keyboard 20, the pointing device 21 and the data storage device 23. Such data accesses are achieved by making the requisite system call to the operating system, which will then implement the necessary functionality and return the requested information. Output is directed to the display 22, a printing device 27 or to a datafile stored on the data storage device 23.

An application implementing the present invention on a conventional personal computer, such as that of figure 10, will now be described. The application was written in a version of the C++ computer programming language using the BorlandTM C++ integrated development environment in combination with the Delphi programming language. The implementation was compiled and linked to run on a computer running the Microsoft Windows NTTM operating system. It will be appreciated that the application could be implemented in any convenient programming language to run under any operating system such as another version of Microsoft Windows or a UNIX based operating system.

The application is conveniently supplied as one precompiled executable application file, together with any requisite libraries and standard data files, on a data carrier such as a Compact Disc Read Only Memory (CD-ROM). In some embodiments, the application may be downloaded to a local personal computer over a computer network such as the Internet from a remote server. This can be conveniently achieved by implementing a website which allows access to the server, access being effected using conventional web browser software.

The application can be considered to comprise three interrelated modules and these will now be described in outline with reference to figure 11. A model building module 28 receives input data from a variety of file and interactive input devices and uses this input data to create a model. A learning and updating module 29 takes historical data and parameterises the model created by module 28 as described above. An optimisation module 30 takes a parameterised model and determines optimal price values. The model is stored in a centralised database 31. The interconnections between these three modules 28, 29, 30 and the database 31 are schematically illustrated in figure 11.

Referring now to figure 12, the interconnections between the modules of figure 11 are shown in greater detail. The activities performed by these modules to create and optimise a demand model are now discussed. The model building module 28 reads input data from a product data file 32 stored on the data storage device 23 of figure 10. The product data file 32 contains details of products which in turn populate the subcategories and categories of the retail outlet. Competitor products that are to be taken into account can be stored in the same file, such products being identified by a suitable flag. The format of the product data file is outlined below.

The product data file 32 will identify the subcategory and category to which each product belongs. As the file is read the requisite categories and subcategories will be created to hold the appropriate products. When the entire file has been read by the model building module 28, a model of the supermarket analogous to that of figure 4 is created. The product data file 32 will also identify subcategory flag products, known as key-cluster items (KCI) and category flag products, known as Known Value Items (KVI). Aggregated products are also identified and therefore a retail outlet model is created in which the number of relationships that are to be considered is minimised is created by the model building module 28 equating to step 1 of figure 1.

The flag products identified in the product data file 32 will have been nominated by a manager, and the aggregations identified will either have been nominated by a manager or by a computer program as described above. In a preferred embodiment of

the invention a utility program independent of the main application will be provided to carry out the aggregation process. Once created, the retail outlet model is written to the centralised database 31. In a preferred embodiment of the invention, this database may be implemented using a conventional Structured Query Language (SQL) database wherein modules of the application will act as clients of the database.

The created retail outlet model representing only the relationships between products within the retail outlet that are considered can then be read from the centralised database 31 by the learning and updating module 29 which will parameterise the demand model as described above with reference to step 2 of figure 1. The form or shape of the demand model is predetermined in the system, the form being stored by the model building module. In order to calculate optimum parameters for the demand model, historical sales data is required and this is read by the learning and updating module 29 from a data file 33. The parameterisation of the demand model is carried out in a top-down manner as described above using a mathematical best fit approach to fit a curve to historical data. Retail outlet level parameterisation calculates the parameter values for the category flag products in each category. Category level parameterisation calculates the parameter values for the subcategory flag products in each subcategory of the category. Subcategory level parameterisation calculates the parameter values for the non-flag products from the subcategory. Only product relationships which comply with the rules defined above are maintained in order to reduce complexity of the resulting model and of the parameterisation process.

In a preferred embodiment of the invention, in order to increase the simplicity of the model still further, categories are considered to operate independently, and in this case category level parameterisation is the first step of the parameterisation process.

Once calculated, the parameters of the retail outlet model are written back to the centralised database 31.

Step 3 of the flowchart of figure 1 involves the specification of constraints on the demand model. Referring again to figure 12, in the illustrated embodiment, these t

constraints are input interactively by the presentation of a GUI on a display device 34.

A suitable form for this GUI is described below. A user may respond to this GUI using input means 35, comprising the keyboard 20 and the pointing device 21 of figure 10. This input is directed from each device 35 to the model building module 28.

The demand model stored by the centralised database 31 is then read by the model building module 28 and updated to reflect the inputted constraints.

The inputted constraints can then be validated by the model building module 28. Cost information is input to the system by a user responding to a GUI presented on display device 34 using input means 35. Optimisation of the demand model stored in the centralised database 31 can now be performed by an optimisation module 35. The model is read from the database 31 by the optimisation module 35. Constraint information relating to price and sales constraints is also read from the database 31.

This reading of data is carried out along channel 36.

The optimisation problem is then solved in a top down manner as described above. Store level optimisation determines the prices of the category flag products from all categories in the store. Category level optimisation determines the prices of all subcategory flag products from all subcategories in the category. At the same time, the prices of the category flag products are kept fixed at the values found during the retail outlet level optimisation. Subcategory level optimisation determines the prices

of all non-flag products from the subcategory. The prices of the subcategory flag t) zn products are kept fixed at the values found during the category level optimisation.

In a preferred embodiment of the invention, in order to increase the simplicity of the model still further, categories are considered to operate independently, and in this case category level optimisation is the first step of the optimisation process.

When the optimisation problem is solved, an optimum set of prices for all products is available and this can be communicated to a user using display 37, by directing output to a spreadsheet file 38, or less preferably by directing output to a printing device 39.

In a preferred embodiment of the system, price information will be displayed to the

user via display 37. The application will then allow the user to select some or all of the optimum prices that have been calculated and copy this selected price information to a file, which may in turn be printed or otherwise manipulated and analysed by the user.

On confirmation by a user that the calculated optimum prices are to be implemented in the retail outlet, this optimum price information and forecasted sales information is forwarded along a channel 40 to the learning and updating module 29. The learning and updating module can then take this data into account in future parameterisations of the demand model. The forecasted sales data allows the effectiveness of the price setting decisions to be monitored, by comparing this data with actual sales occurring in the retail outlet after implementation of the calculated prices.

Referring now to figure 13, a suitable format for the product data file 32 is shown.

The purpose of each field shown in the figure will now be briefly described. Field I relates to the frequency with which the model is updated, and this information is of primary interest to the learning and updating module so that it knows how frequently data about each product will arrive. The field value is represented by a single character, for example W if the model is updated weekly, M if the model is updated monthly.

Field 2 is used to identify the retail outlet. This is particularly useful where a model representing a segment is to be used. Similarly, fields 3 and 4 identify categories and subcategories respectively. Fields 3 and 4 will be used to identify in which category and subcategory each product should be placed. If the specified subcategory or category does not exist, the appropriate subcategory will be dynamically created when the product data file is read. Field 5 is a unique identifier for each product, while field 6 is used within the system to discriminate between products sold in the retail outlet in which pricing decisions are made, and those sold by competitors. Field 7 is used to identify a KCI, or subcategory flag product. Field 8 is used to identify a KVI or category flag product. Fields 7 and 8 take the form of a simple Boolean flag, that is I for true, 0 for false.

Fields 9 to 12 identify the product to managers containing brand, product, type of packaging and size information, in a human readable form. These fields can also be used to automate aggregation decisions as described above whereby a computer will compare a number of essential fields to ensure that they are all identical if aggregation is to occur. Four constraint fields then follow. Fields 13 and 14 specify minimum and maximum prices respectively. Fields 15 and 16 represent the sales constraint information. Flag 17 is used where manual aggregation is performed, or where aggregation is performed by a separate utility program as described above, to identify to the system when a product is in fact representative of a number of different products.

The product data file will contain one record for each product in the retail outlet and also one for each product that is sold by a competitor and is considered to be of interest to the current pricing scenario. Competitor products may be identified by setting the flag of field 6 to a 0 value. Records for competitor products will contain null values for fields 13 to 16 as setting constraints relating to pricing of competitor products is not meaningful. In a preferred embodiment of the present invention, competitor products are listed after own products in the product data file 32.

In the described embodiment, competitor products and those sold by the outlet in which pricing is taking place are held in a common file, represented by a flag.

In a preferred embodiment of the present invention a manager of a retail outlet will provide a software supplier with information about the departments and shelves (relating to categories and subcategories respectively) within their store, together with details of products that are sold by the retail outlet. The file described above is then created by the software supplier. A GUI may be provided as part of the application to allow users to create their own files, or alternatively to edit the file supplied as described above.

It will be appreciated that the file format of figure 13 is intended only as a representative example and any suitable file format could be used to input category, subcategory and product data. The file as illustrated will be processed by the model building module implementing a parser to read and interpret the input file.

For example, in an alternative embodiment of the invention, separate files may be used for each hierarchy level to specify elements of that level within a retail outlet before the product data file is read in, thus removing the need for dynamic creation of the levels and elements of the hierarchy as the product data file is read.

As described above, a GUI may be implemented to allow specification of price and sales constraints and this is illustrated in figures 14 to 16. The illustrations are taken from an implementation of the invention known as PriceStrat.

Referring first to figure 14, a main window 41 containing the PriceStrat application comprises a menu bar 42, a button bar 43, a field 44 identifying a location of the centralised database that is currently in use, a pane 45 representing which model is currently in use and a pane 46 which forms a hierarchical or tree display of the categories, subcategories and their constituent products. A further pane 47 holds information dependant on the current task being undertaken by the application.

The menu bar 42 provides five menus, some of which are themselves provided with submenus or options that display dialog boxes. A database menu allows import of data from standard format files such as comma separated value (CSV) files to the centralised database. A search menu provides a conventional search function whereby a user may search to locate a given product, subcategory or category stored in the centralised database. A model menu provides system configuration functionality, allowing switching between an edit mode and a browse mode. The model menu also allows specification of file paths for system files, and configuration of date format to be used within the system. An actions menu provides functionality to specify and configure constraints discussed above, as well as a trigger to activate a constraint validation function. Finally, a help menu provides version and build information.

The button bar 43 provides six buttons. An edit button 48 allows editing of the currently loaded model, a browse button 49 allows browsing of the currently loaded model, an optimise button 50 performs optimisation of the model as described above, and a parameterise button 51 performs parameterisation as previously described. A delete button 52 allows products to be deleted from the hierarchical structure of pane 46, and an Import Historic Data button allows importation of data that may be used to calculate parameters as described above.

Referring now to pane 47 of figure 14, it will be seen that eight tabs 54 are provided, the currently selected tab being price differentials. This allows the specification of constraints according to equation (12), that is, price of a product relative to another product sold in the same outlet. Referring now to the data 55 within pane 47, record 55 comprises seven fields. A first field 56 identifies the subcategory to which a first product of a price differential belongs. A second field 57 identifies the subcategory to which a second product of the price differential belongs. A third field 58 gives an identifier of the first product while a fourth field 59 gives an identifier of the second product. It will be noted that no category is identified for each product because the illustrated implementation assumes that categories act independently, as described above, that is products 3120 and 3121 are implicitly members of the same category.

Field 60 equates to pos V, roof equation (12) above, while field 61 equates to pots", of III in x equation (12) above. Each constraint may be activated or deactivated, and field 62 holds this information.

It can therefore be seen from record 55 of figure 14 that the price of product 3121 must always be between 90 pence and f 1. 20 more than that of product 3120.

Pane 47 also contains a button bar 63 providing buttons that allow records as exemplified by record 55 to be added, removed or edited. A button is also provided to switch activation of a constraint, and this status is shown in field 62.

Referring now to figure 15, here the product information tab 64 is illustrated. A product ID field 65 holds a product identifier, and four fields 66 are provided containing information to allow a user of the application to more easily identify the product in terms of description, brand, size and type. A field 67 is provided to report when the price of the product that is currently being viewed was last optimised. A group of fields 68 allows the specification of price fluctuation constraints. as described above with reference to equations (4) and (5). The variable of equation (4) is represented by a"Dec"field 69 while the variable of equation (5) is represented by an"Inc"field 70. Fields are also provided to specify the increment or decrement values in terms of a percentage. Area 71 of pane 64 of figure 15 holds other product specific details recording whether or not the product is aggregated and whether or not it is a KVI or KCI. A further area of product information tab 64 allows the loading of an image of the product in the form of a standard bitmap file for ease of identification by a manager.

Referring now to figure 16, a pane 72 for input of price and sales constraint data is shown. Referring to sub-pane 73, cost information for a product being viewed is shown, together with the maximum and minimum price bounds that have been specified (as described above with reference to step 3.2 of figure 8). The current price of the item is also displayed. A graph 74 gives a graphical indication of the relationship between the current price, the cost and the specified maximum and minimum bounds.

Sub-pane 74 contains sales constraint data as described above with reference to equation (13). A"minimum"field is used to specify the value for the Slower term while a"maximum"field is used to specify the value for SliPper'A "last actual" field is used to display previous sales figures that have been read from the historic data file.

Other tabs are provided by the application which are not illustrated in the figures.

The functionality provided by each of these will now be briefly described. It will be

observed that the tabs shown in figure 14 are different from those shown in figures 15 t) t : l

and 16. This is because the tabs displayed are dependant on what is selected in the hierarchical view 46. In figure 14 Cooked Meats is selected which is a subcategory, the tabs displayed are therefore those relevant to a subcategory. In figures 15 and 16 product 3120 is selected, that product being a member of the Cooked Meats subcategory. The tabs displayed in figures 15 and 16 are therefore those relevant to a product.

In general terms, when a product is selected, Product Information, Product Prices and Sales, Historical Data and Price Points tabs are displayed, but as these can not sensibly be applied to a subcategory, they are not shown in figure 14, where a subcategory is selected. When a category or subcategory is selected, Price points applicable to all products in that category or subcategory may be set by selecting the appropriate choice from the Actions menu. If a product is selected as in figure 15 or 15, there is no Price Differentials tab. This is because a price differential (that is a price positioning constraint) involves two products.

Each of the tabs shown in any of figures 14 to 16 will now be described. A store information tab displays basic information relating to the name, address, and telephone details for the outlet in which pricing decisions are to be made. A category tab provides a brief description of a category together with historic sales data for that category, and bounds on total sales for the category. Similarly, a subcategory tab displays information describing a sub category and also displays information relating to historic total sales, bounds on total sales, and any price point specification that is applicable to all products in the subcategory.

An historical data tab allows display of historical cost, price and sales data. If the tab is selected from a category or a subcategory, data for all related products is displayed.

An optimum price tab displays sales and profit data for a given product price decision.

Thus, this tab also allows a user to perform "what if'analysis. A user can change product prices and observe the forecasted effects on sales and profits for the same and other products. This tab could be easily amended to function with optimisation criteria other than profit as described above. A price point tab lists price point specifications.

If this tab is selected while a category or a subcategory is selected, the price points shown are applicable for all related products.

An elasticities tab displays relationships of a selected product with other products and the corresponding price elasticities. If the tab is selected from a subcategory, the elasticities for all products related to that subcategory are displayed. If the tab is selected from a category, the elasticities for the flag products parameterised and optimised at this level are displayed. It has been mentioned above that cost information does not include purchase tax. A taxes tab is therefore provided to display a list of available tax rates, one of which is activated. If this tab is selected from a category or a subcategory, the tax rates applicable for all related products are displayed. Finally, a log tab is provided to display configuration information about log files locations. The system reports the results from all main functions into log files for auditing purposes.

In the above description of the tabs provided by the GUI, it will be appreciated that references made to the display of information may equally refer to a case where a user is permitted to additionally edit displayed data.

It will be appreciated that any file input described above may be replaced by any other convenient form of input such as interactive input using a GUI. Similarly, references to use of a GUI for input may be replaced by suitable input data files.

In an alternative embodiment, the invention may be operated over a computer network wherein the database 31 (of figures 11 and 12) is stored on a separate database server. The modules of the application would then run on a separate personal computer linked to the database server by means of a local area network (LAN) or a wide area network (WAN). Furthermore, the modules of the application as illustrated in figure 12 may be distributed between computers connected to the network. This

w will be particularly useful where the invention is used in a segment of retail outlets, I I tn

each of which is in a geographically distinct location, or alternatively in one retail outlet where more than one user requires access to the system.

It will be apparent to those skilled in the art that the method of implementation described herein may be varied using conventional software engineering techniques.

The embodiment of the invention as described above relates to the application of the method of the invention to a large scale retail outlet allocating products to categories and to subcategories within those categories. Although such a hierarchy is in wide spread use within the retail sector, it will be appreciated that the method of the invention is not restricted to such a hierarchy. Furthermore, the invention is not restricted to use only in large scale retail outlets, but is instead widely applicable in a wide range of differing areas in which pricing or other strategic decisions are to be made.

A product hierarchy having a different number of levels and different elements at each level can be accommodated by the method of the invention. For example, a company may have an extra department level in the product hierarchy with each department comprising one or more categories. In this case each category node of figure 4 will be a child of a department node.

The rules dictating possible inter-product relationships within the hierarchy can be trivially amended to cater for a product hierarchy having an extra level. In general, a predetermined flag product for a non-leaf element in the structure of figure 4 is modelled to have relationships with the following product types: Flag products of other elements at the same level in the hierarchy ; Flag products of the immediately lower level element of the hierarchy, within the same element of this lower level as the predetermined flag product; Key competitor products (flag products for a corresponding hierarchy level and element in a competitor store.).

It will be appreciated that the expansion of the product hierarchy will involve additional parameterisation and optimisation steps.

Claims

CLAIMS 1. A method for modelling relationships between a plurality of products sold by a retail outlet, wherein each product to be modelled is allocated to a category, such that a model is created containing a plurality of categories each containing a plurality of products, at least one product in each category is nominated to be a category flag product, relationships between products within the same category are modelled, and relationships between two products allocated to different categories are modelled only if the two products are both category flag products.
2. A method according to claim 1, wherein any product not nominated to be a

category flag product, is modelled to have relationships only with category flag t : l products.
3. A method according to any preceding claim, wherein the relationships to be A metl modelled represent cross elasticity.
4. A method according to any preceding claim, wherein at least one product sold by a competitor of the retail outlet is also modelled.
5. A method according to claim 4, wherein the product sold by the competitor is modelled only if it corresponds to a category flag product.
6. A method according to claim 4 or 5, wherein relationships between the product sold by the competitor and products sold by the modelled retail outlet are modelled only in the case of category flag products.
7. A method according to any preceding claim, wherein the retail outlet is modelled in an hierarchical manner, whereby each category is modelled to contain at least one subcategory, and a product allocated to a predetermined category is allocated to a subcategory contained within said predetermined category.

<Desc/Clms Page number 44>
8. A method according to claim 7, wherein at least one product in each subcategory is nominated to be a subcategory flag product.
9. A method according to claim 8, wherein a product not nominated to be a subcategory flag product is modelled to have relationships only with products in the same subcategory.
10. A method according to claim 9, wherein a product not nominated to be a subcategory flag product is modelled to have relationships only with subcategory flag products.
11. A method according to any one of claims 8 to 10, wherein a relationship between a first product allocated to a first subcategory of a first category, and a second product allocated to a second subcategory of the first category is modelled only if said first product and said second product are both subcategory flag products.
12. A method according to any one of claims 8 to 11, wherein a category flag product is modelled to also be a subcategory flag product.
13. A method for modelling relationships between a plurality of products sold by a group of retail outlets, wherein each retail outlet is modelled using a method

according to any preceding claim, and relationships between at least one pair of t : 5 category flag products in different retail outlets are modelled.
14. A method according to any preceding claim, wherein at least one modelled L-1 product is an aggregation of a plurality of products sold by the retail outlet.
I 1=1 IS. A method according to claim 14, wherein the aggregation is performed by computer, using predetermined criteria.
16. A method according to claim 15, wherein the criteria comprise brand, price, size, packaging type, customer type, cost or usage.

<Desc/Clms Page number 45>
17. A method of determining an optimum set of prices for a plurality of products sold by a retail outlet, comprising modelling relationships between said plurality of products using a method according to any preceding claim, using the modelled relationships to create a demand model of predetermined form, determining parameters for said demand model to generate a parameterised demand model, and using said parameterised demand model to determine a set of prices which yields an optimum value for a predetermined optimisation criterion.
18. A method according to claim 17, wherein parameterisation is carried out using a mathematical best fit approach to fit the demand model of predetermined form to a set of historical data.
19. A method according to claim 17 or 18 as dependant upon any one of claims 8 to 12, wherein parameterisation is carried out in a top down manner such that parameter values associated with category flag products are calculated before parameter values associated with subcategory flag products.
20. A method according to any one of claims 17,18 or 19 as dependant upon any one of claims 8 to 12, wherein parameterisation is carried out in a top down manner such that parameter values associated with category flag products and parameter values associated with subcategory flag products are calculated before parameter values associated with other products.
21. A method according to any one of claims 17 to 20, as dependant upon claim 13, wherein parameter values associated with products nominated by each retail outlet are calculated before parameter values associated with category flag products.
22. A method according to any one of claims to 17 to 21 as dependant upon any one of claims 8 to 12, wherein optimisation is carried out in a top down manner such that optimum price values associated with category flag products are calculated before

optimum price values associated with subcategory flag products.

I

<Desc/Clms Page number 46>
23. A method according to claim 22, wherein the price of each category flag product is calculated prior to the calculation of an optimum price for any subcategory flag product.
24. A method according to any one of claims 17 to 23 as dependant upon any one of claims 8 to 12, wherein optimisation is carried out in a top down manner such that optimum prices for category flag products and optimum prices for subcategory flag products are calculated before optimum price values for other products.
25. A method according to any one of claims 17 to 24, wherein optimum prices

are subi : nts. are subject to one or more constraints.
26. A method according to claim 25, wherein prices of a product are constrained t with reference to: the price of another product sold by the retail outlet, and/or cost of the product, and/or a previous price of the product, and/or a price of a product sold by a competitor and/or a predetermined price point of the product.
27. A method according to any one of claims 17 to 26, wherein the predetermined optimisation criterion is profit.
28. A method according to any preceding claim, wherein the model of the retail outlet is held in a database.
29. A method according to claim 28, wherein the database is implemented using Structured Query Language.

10.
30. A method according to any preceding claim, wherein the method is implemented by a computer
31. A method according to claim 30, wherein the method is carried out on a plurality of computers, each computer connected to a computer network.

<Desc/Clms Page number 47>
32. A computer readable file storing a plurality of records, each record comprising data relating to a product sold by a retail outlet, wherein each record comprises a product identifier and an identifier of a category with which the product is associated, and the file further comprises an indication of at least one product in each category that is nominated as a category flag product.
33. A computer readable file according to claim 32, wherein each record includes a field for storing data indicating if the product is a category flag product.
34. A computer readable file according to claim 32 or 33, wherein each record further comprises an identifier of a subcategory with which the product is associated.
35. A computer readable file according to claim 34, wherein each record further comprises an indication of at least one product that is nominated as a subcategory flag product.
36. A computer readable file according to any one of claims of 32 to 35, wherein the file further includes at least one competitor product record, the or each competitor product record representing information about a product sold by a competitor, and each competitor product record comprising a product identifier.
37. A computer program element comprising computer program code means for creating a model of a retail outlet comprising a parser for reading a computer readable file according to any one of claims 32 to 36.

n 9.
38. A computer program element comprising computer program code means for carrying out a method according to any one of claims 1 to 31.
39. A carrier medium carrying computer readable code for controlling a computer to carry out procedure according to the method of any one of claims 1 to 31.

<Desc/Clms Page number 48>
40. A carrier medium according to claim 39, wherein the carrier is a CD-ROM or a communications line.
41. A server comprising a connection to a computer network and means for remote access from a remote computer connected to the computer network, wherein the server stores a computer program element according to claim 38 and allows a user to access said computer program element.
42. An apparatus allowing a user to access or manipulate a model created using a method according to any one of claims 1 to 16, comprising output means for displaying the model to a user, user interaction means for allowing a user to select or edit part of the model, processing means responsive to said user interaction means for manipulating the model, and computer program code means for controlling said processing means.
43. An apparatus according to claim 42, further comprising non-volatile data storage means for storing the model.
44. An apparatus comprising a non-volatile storage medium, the medium having thereon a model created using a method according to any one of claims 1 to 16.
45. An apparatus for carrying out a method according to of any one of clams I to

31.
46. A method substantially as hereinbefore described with reference to the accompanying drawings.
47. An apparatus for carrying out a method substantially as hereinbefore described with reference to the accompanying drawings.

<Desc/Clms Page number 49>
48. A computer program element comprising computer program code means for carrying out a method substantially as hereinbefore described with reference to the accompanying drawings.
49. A carrier medium carrying computer readable code for controlling a computer to carry out a method substantially as hereinbefore described with reference to the

accompanying drawings.

Z7,