Qusai Sarraf and Gerard Ellis of IVIS describe rules-based B2C and B2B systems in the biggest on-line grocery store in the world, with the business rules owned by business people -- John Hall

Business Rules in Retail: The Tesco.com Story

Qusai Sarraf and Gerard Ellis

IVIS Group Limited, CP House, 97-107 Uxbridge Road, Ealing, London, W5 5TL info@ivisgroup.com.

Abstract

UK-based Tesco.com is the Internet arm of Tesco Plc, the third-largest retailer in the world. Tesco.com is the largest on-line grocery store in the world, with annual turnover exceeding $2b; it also retails electrical products and other goods from its parent. It has adopted the Sonetto platform from IVIS Group to develop systems driven by business rules in several different contexts, including on-line purchasing of wine and electrical goods, interaction with affiliate companies and shopping comparison services, and provision of health and dietary information to customers. The business rules in all of these applications are developed and maintained by business users.

Introduction

Bricks and mortar retailers are investing in multi-channel initiatives including online stores and catalogues to broaden their market reach and gain competitive advantage. At the same time, diversification and collaboration initiatives are growing. Diversification initiatives include increasing the range of products and services offered and entering new markets and geographies. Collaboration and partnership strategies create alliances in the sourcing, fulfilment and sales functions that broaden market reach.

All of these strategies entail a massive increase in the amount of information a retailer has to manage. We assert that the only effective solution in dealing with the challenges of retail information management is to turn to the most valuable asset in any organisation, knowledge. However, organisational knowledge is vast and irregular and there are many examples of failed attempts to tame the process of acquiring and harnessing knowledge. Turning to Enterprise Business Rules is the logical approach; however, the question is how to commercialise the process of creating business rules and provide this mechanism to those who needed it - the business users.

Tesco.com is the largest online grocer in the world with annual turnover exceeding $2b. It is the online arm of Tesco Plc., the third largest retailer in the world with annual revenue exceeding $70bn.This article tells how Tesco.com partnered with IVIS Group, a UK based multi-channel e-business expert, to meet the challenges of enterprise business rules head-on - and win.

Challenges

Traditionally, retailers invested heavily in optimising their supply chains and processes. Enterprise Resource Planning (ERP) initiatives that have taken years to implement and cost millions of dollars are geared towards streamlining processes which have been maturing for many years - in buying, transporting, storing, merchandising and subsequently selling products. These traditional systems have led to ‘stove pipe’ information architectures that are hindering rather than helping the implementation of new strategies.

Retailers are facing the following challenges in striving to implement multi-channel information management capabilities:

• Multiple sources of increasingly dynamic product information
• Poor quality of information from an increasing number of 3rd party data providers
• Multiple internal and external stakeholders, especially customers, with different informational needs depending on the channel
• Absence of standard definitions of data and processes
• Increasing customer expectations for richer product information through multiple channels

Dealing with the challenges

Retailers have taken a number of steps in dealing with the above challenges. These measures range from outsourcing manual data management to building technically driven in-house applications and purchasing dedicated IT solutions.

IT investments have typically included catalogue management systems, search tools, data extraction and cleaning tools, category and catalogue management systems and Product Information Management (PIM) solutions. However, these solutions typically suffer from over-reliance on IT, fixed product definitions or schemas and the need for manual, time consuming and expensive cleaning and enrichment of data.

Sonetto, a unique solution to a common problem

Sonetto is a rule-based Multi-Channel Product Information Management solution targeted at business users. At the heart of Sonetto there is an enterprise rule engine which provides services to store and retrieve semantic information. Business users interact with the core rule engine through three applications:

• Enrichment engine – Defining new products, editing and extending existing products and attributes
• Categorisation engine – Slicing and dicing product information in different categories, providing different views to multiple stakeholders
• Discovery, or Search engine – Searching, validating and discovering information, associated patterns and relationships by business users and end-customers

Figure 1 shows the Sonetto component architecture:

Figure 1: Sonetto component architecture

Overview of Sonetto at Tesco.com

Sonetto is being used by Tesco.com in three different areas that demonstrate the value of business rules as the basis for solving very different information management challenges:

Tesco.com uses Sonetto to manage product information for its Electrical and Wine categories, allowing business users to take control of the quality of product information regardless of the quality and lack of standards in the source data. This allows business users to provide online customers with content-rich, customer-centric information and demonstrates a Business-to-Customer (B2C) application for business rules.

Affiliate networks and Shopping Comparison services (like Kelkoo) generate a large proportion of Tesco.com’s electrical and entertainment revenue. However, there were many challenges in managing this channel including the need to communicate with a myriad of partners who require product data according to different definitions, formats and categorisation structures. Tesco.com business users use business rules to fulfil the Business-to-Business (B2B) function of managing the product data feeds to these partners.

Finally, to capitalise on the increasing demand by consumers for health and dieting information and services, Sonetto was implemented for a third time in Tesco.com to enable business users to create dynamic rule-based linkages between recipes, ingredients and products. This demonstrates a Business-to-Employee (B2E) application.

Principles of the Sonetto Knowledge Management Approach

Sonetto has been designed using the following principles:

• Business rules are written by business users, not IT nor restricted to specialist rule authors
• Individual tasks or domains require specific sser interfaces for rule building for general users
• Business users build rules in-situ through normal editing or interaction with a system and its context
• Rule building is activity centric in a rich set of business workflows
• A maintenance approach is the foundation as it is assumed rules are incomplete and will evolve over time
• Users must be given confidence in the system by showing impact of rule change in real time (testing), through evaluation over a repository. Users need to see actual cases affected, and summaries or auto categorisations of groups of affected cases
• Rule building scales at the human level through users not focusing on rules, but on editing documents in normal interactions, and justifying change
• Rules and their interdependencies are managed by contexts using Ripple Down Rules, so that change is localised to the current context, resulting in stable rule building
• Allow users to say or interact as needed through a bottom up approach to schema management which means no IT involvement
• Use powerful knowledge representation to capture contexts, rules, categories, schemas. We use the Conceptual Graph formalism as Sonetto’s foundation.

Individual Tasks or Domains Require Specific User Interfaces for Rule Building

Since general business users hold much of an enterprise’s knowledge, a goal is to capture that knowledge whilst minimising any change or training required to capture that knowledge. This means that Sonetto is ideally invisibly integrated into existing applications or used to develop specific interfaces for the tasks undertaken by the user. Whilst it is possible to write declarative rules in some logic, or formal controlled language such as Controlled English [4] , or use systems such as RuleSpeak [1], many users would prefer if they were not presented with such an open-ended opportunity to build rules. Rather a simpler task of justification of the change made in context is more achievable for many users.

A major part of rule building is identifying the conclusion or action to be taken in the context of a given task with some data. Capturing this interaction or change by the user is required. Typically, this involves adding, removing or modifying some information. The information removed or modified may or may not have been previously generated by existing rules captured by Sonetto.

Sonetto provides specific user interfaces for product management, product standardisation, promotion management, and has been the basis for the recipes solution. Sonetto then captures the change, the case or data being changed and then allows the justification of this change in user friendly interfaces. Sonetto can be integrated into existing applications or extend those applications as well.

Kinds of Rules Acquired

The following examples illustrate the kind of rules that have been captured using Sonetto at Tesco.com in the Product Information Management and Affiliate Management applications, though they are for explanation purposes only and are not actual Tesco.com rules. Rules 4 b) and 7 illustrate customer targeted rules which are possible as suggested as key for personalisation [8] .

1. If a television product description contains “28-inch screen”, add a screen_size attribute_inches with a value of 28.
2. The click through rate for the Shopping comparison service Kelkoo is the negotiated value of 50 cents for camera accessories.
3. Add the attribute ‘type’ with value ‘Playstation’ to Kelkoo affiliate product information if category hierarchy level 2 is ‘Gaming’ and gaming type is ‘PS1’.
4. a) If a recipe ingredient contains butter, suggest “Gold Butter” as an ingredient to add to the basket. b) If the customer prefers organic dairy products, suggest “Organic Butter” as an ingredient to add to the basket.
5. If a customer buys two packets of biscuits, the customer gets one free.
6. If the basket value is over £100, delivery is free.
7. If the customer is a family with children, suggest buy one family sized pizza and get one free.

The first rule illustrates the type of rule that would be built during a product standardisation activity. In this activity unstructured product data would be converted into a standard structured data model.

The second and third rules are examples of rules that would be constructed in mapping product data to a shopping comparison partner such as Kelkoo.

The fourth a) and b) is the kind of rule that would be captured in a recipe management system and the fifth, sixth and seventh are simple examples of rules that would be captured when managing promotions.

Ripple Down Rules: A Maintenance approach to Rule Acquisition

Sonetto is based on the Ripple Down Rules (RDR) framework for rule acquisition [5] [6] . Users make conclusions about a case. In Sonetto, a ‘conclusion’ corresponds to some editing action such as changing, adding, or removing an attribute value or relationship. Cases in Sonetto can be products, customers, recipes, etc. When a user changes an attribute value of a case, they are asked to justify the change (add conditions for the rule). This rule is added in the context of the rule that gave the modified attribute value.

The following shows the steps to add the rule “Products over £250 have a delivery cost of £0.00.” A user would already be in a category of products such as Electrical > Home and be looking at a product such as “Hotpoint Washer Dryer”

• Add attribute delivery_cost with a value of £0.00
• Justify the edit because price > £250 by selecting this condition from the Hotpoint Washer Dryer.

The RDR rule tree is simply

	If price > £250 Then
		Delivery_cost is £0.00

An exception to this rule may be “Products which weigh more than 100 KG have a £10 delivery charge.” The user would create this rule when they had been reviewing a product such as “Double Fridge/Freezer” which has the inferred delivery_cost from the previous rule. They would then:

1. Modify the delivery_cost from £0.00 to a value of £10.00
2. Justify the change because weight > 100 KG.

The modified delivery_cost of £0.00 already had a condition (context) of price > £250, so the user is only adding a portion of the rule. This context based editing means any change is constrained to minimise unintended consequences.

The RDR rule tree is then modified to

	If price > £250 Then
		If weight > 100KG Then
			Delivery_cost is £10.00
		Else
			Delivery_cost is £0.00

Note that a major part of the task of rule building is editing or interacting with the current task and context. The justification part can be done asynchronously by the same or different users or a machine learning system.

The user could then be reviewing these rules coming up to a holiday period, where they want to put on a delivery charge of £5.00 from the normal £0.00.

The user could select some product say the “Hotpoint Washer Dryer” used previously or other with delivery_charge £0.00. They then do the following tasks.

1. Modify the delivery_cost from £0.00 to £5.00
2. Justify the change because holiday_period

The RDR rule tree is then modified to:

	If price > £250 Then
		If weight > 100KG Then
			Delivery_cost is £10.00
		Else
			If holiday period Then
				Delivery_cost is £5.00
			Else
				Delivery_cost is £0.00

The complexity of the steps of editing and justification are fixed, whilst the decision trees that are maintained by RDR are growing in complexity. Nested if-then-elses with cyclomatic complexity greater than 10 (number of paths through the code) are not maintainable [11] . Experience at Tesco.com has shown that the rule bases built performing their tasks are very complex when seen in a nested form or in a purely declarative form. RDR scales because users do not need to see the rule trees. They are verbalised on the cases as justifications for the conclusions already added by the rule base. Consequently users don’t have search or browse for rules to change, they are referenced on documents/cases affected, they only have to modify any existing conclusion and justify the change.

User Confidence in Impact of Rule Changes

Users need to understand the impact of adding a rule to the system.

RDR is rule building by example. The example is the case that was edited before going into the rule builder for justification, and is called the current case, or cornerstone case. When building the conditions for the justification, users are presented with the current case and the cornerstones cases of the other rules that are affected by the rule under construction. The set of cornerstone cases affected by the rule is called the conflict set.

Initially a justification (condition set) of a rule is empty, so it affects all cornerstone cases. As the user picks conditions from the current case, the condition becomes more specific. This shrinks the conflict set, as less cornerstone cases will match the justification.

To exclude a cornerstone case from being affected, the user picks the excluding features from that case, which are turned into a negative conditions. This again will shrink the conflict set.

In the previous example, modifying the delivery cost from £0.00 to £10.00, was done in the context of products with prices > £250. The user could have chosen from the current case that weight > 100KG. After they have added the condition they would then be left with conflict cases where prices > £250 and weight > 100KG. The user refines the conditions until the conflict set consists of those cases the user intends to have the rule applied to.

RDR is typically implemented in two separate activities: validation and rule building. In the validation activity, cases have been enriched by the rule engine and are reviewed or possibly edited (corrected) by the user. In the rule building phase, a user reviews cases which have been modified by the user or other users. A rule is added to automate the editing change. RDR systems are highly accurate, usually achieving 98% correctness or higher [6]. Hence the number of cases reviewed in the rule building activity is 2% of those seen in the validation activity as shown below in the transaction model.

Figure 2: Rule and Case Maintenance

This separation of validation from rule building is particularly suited to the pathology applications where RDR has been used. This is because pathologists typically cannot modify pathology reports which have already been issued. Hence, only examples used to build rules are recorded.

In Sonetto, as well as maintaining rules, users are also maintaining all the cases in a repository (see the repository model in figure 2). Each rule can potentially edit a large proportion of a vast repository of cases. Consequently, when justifying a change in the rule builder all cases are considered not just cornerstone cases.

In RDR, normally several cornerstone cases need to be reviewed, but in our case we have potentially orders of magnitude more cases to review. The number of conditions added for each rule is still the small number experienced in other RDR systems. Sonetto users can review the cases affected through an automatic hierarchical view of the cases constructed over relevant attributes. They can navigate through these cases to validate there are no further exceptions to the rule.

Each conclusion is a category of products which can also be explored, so reviewing a set of rules which give the same conclusion.

RDR supports continuous testing similar to that proposed by Berlandier [7].

Efficiency of Rule Maintenance

We have confirmed what has been shown in other domains that RDR systems allow general users to add a rule in a few minutes independent of the number of rules in the system [6] [4] . What normally took several days of IT time, and also that of commercial people instructing IT, takes several hours of the commercial person’s time per month to maintain product data. The quality is also much higher.

Schema Management: Bottom-up and Top-Down

Sonetto supports both top-down and bottom-up approaches to data schema management. Whilst there is central control over the semantic schema that allows a design first approach, Sonetto supports users extending schemas in a controlled fashion through rule-based editing of product data. This eliminates the need for costly IT staff and software delivery cycles to support this open-ended growth and maintenance of the data. Users can alternatively, use an administrator to control changes to the schema and control users editing of data.

A Solid Logical foundation

Sonetto uses the Conceptual Graph (CG) logic formalism [2] as its basis for representing documents, rules, categories and schemas. CGs express meaning that is logically concise and human readable. There are a number of forms of CGs including the computer readable CGIF form, and a graphical notation. CGIF is part of the forthcoming ISO Common Logic Standard [3] . For example, the following graphical Conceptual Graph represents that a product has a price of £251.00 and a delivery_cost of £0.00.

A CG consists of two kinds of nodes: concepts and relationships. The following diagram shows the same statement in the graphical form.

Figure 3: Conceptual Graph (CG)

In this example there are 3 concepts: a product, and two currency amounts. There are two relationships: price relating product to a currency and delivery cost relating the same product to a currency. The following is the computer processable CGIF form

[Product: *p] (price ?p [Currency: "£251.00"]) (delivery_cost ?p [Currency: "£0.00"])

A Unique combination of Scalable Rule Engines and Semantic Search Engines

Sonetto requires highly scalable semantic search engines and rule engines because of the volumes of data involved. The semantic search engine is required to find and navigate through the affected documents when rule building and categorisation of documents according to conclusion or other attributes within documents.

Sonetto builds on the knowledge processing work done in [9] and [10] which focused on classification of Conceptual Graph contexts as a basis for organising knowledge. This is a central operation in a semantic search engine and a rule engine. Sonetto’s engines are a fourth generation of these techniques.

Semantic Rule Search Engine Example Case

Consider application of rules to the following situation:

“A recipe with ingredients milk, butter and sugar which is presented to a customer who prefers organic food.”

Figure 4: CG of Recipe

Now given a rule

“if a recipe with a butter ingredient is presented to a customer who prefers organic food, then suggest “organic butter” (is added to the basket)”.

Figure 5: CG of Recipe with rule

After the rule is applied, we have

“A recipe with ingredients milk, butter and sugar which is presented to a customer who prefers organic food, where ‘Organic Butter’ is suggested to add to the basket for the butter ingredient”.

Figure 6: CG of Recipe after application of rule

Here the key operation is projection [2] where the graph representing “a recipe presented to a customer who prefers organic food” projects into (is a generalisation of) the graph for “A recipe with ingredients milk, butter and sugar which is presented to a customer who prefers organic food.”

A search for generalisations is the first phase of the two phase problem of classification discussed in [9] and [ [10] . The highly efficient Sonetto Rule Engine uses generalisation search to find rules which apply to a more specific situation/case.

Semantic Search Engine

Semantic Search [13] is a kind of projection or matching of a query into the semantic network which is the semantic web.

The following shows some possible queries over the semantic web: “wine”, “Australian wine”, “Australian Merlot”, “Nick Bruer Merlot”, “Temple Bruer Reserve Merlot” which are refinements of each other, respectively.

Figure 7: Refinement of Semantic Web queries

Each of these queries is a generalisation of the Temple Bruer Merlot Reserve below. This search for specialisations is the second phase of the classification algorithms in [9] .

Figure 8: Specialised Semantic Web query

By using Sonetto’s rule acquisition system, Sonetto can take unstructured data and highly structure it, to build highly enriched structured data. This enables ever richer semantic search and exploration.

Commercialisation of the Semantic Web 2.0

Folksonomies [12] are an example of categorisation and rule building that Sonetto has sympathy with. Rather than focus on bottom-up development of Taxonomies, we are focused on approaches that allow folk to categorise and tag in an open way as they require, whilst providing support to build a folk or community view.

Conclusion

At the heart of the challenges facing retailers today is the need for the business to take control of the process of information management. Traditionally, this process is left in the hands of the IT department. However, to compete, organisations need to be agile so they can grasp opportunities in an increasing challenging, dynamic and complex market.

The key to addressing these challenges is to harness business knowledge to manage the information. Hence the need for an agile and business-focused system that takes a holistic approach; serving the needs of all stakeholders including customers, partners and employees.

This paper has outlined how Tesco.com uses business rules through Sonetto to achieve its targets and to grow the most successful online grocer in the world.

References

[1]  Ronald G. Ross, "The RuleSpeak® Business Rule Notation," Business Rules Journal, Vol. 7, No. 4 (Apr. 2006), URL: www.BRCommunity.com/a2006/b282.html

[2]  John F. Sowa, “Conceptual Structures: Information Processing in Mind and Machine,” Addison-Wesley, Reading, MA (1984).

[3]  Information technology — Common Logic (CL) – A framework for a family of logic-based languages, ISO/IEC JTC 1/SC 32 N 1377, 2005-12-10,ISO/FCD 24707,ISO/JTC 1/SC 32/WG2,ANSI working draft. URL: http://cl.tamu.edu/docs/cl/32N1377T-FCD24707.doc

[4]  John F. Sowa, “Controlled English” (1999),URL: www.jfsowa.com/logic/ace.htm

[5]  Paul, J. Compton and Robert Jansen. “A philosophical basis for knowledge acquisition.” Knowledge Acquisition 2: 241-257 (1990). (This paper first appeared in EKAW 89) URL: www.cse.unsw.edu.au/~compton/publications/1989_EKAW.pdf

[6]  Paul Compton, Lindsay Peters, Glen Edwards, and Tim G. Lavers, “Experience with Ripple-Down Rules,” Knowledge-Based System Journal. (2006 in press) (This paper first appeared in AI2005, the British SGAI conference) URL: www.cse.unsw.edu.au/~compton/publications/2005_SGAI.pdf

[7]  Pierre Berlandier, "Changing the Rules of Testing ~ Testing Strategies for the Production Maintenance of Rapidly Evolving Business Rules Systems," Business Rules Journal, Vol. 7, No. 2 (Feb. 2006), URL: www.BRCommunity.com/a2006/b270.html

[8]  Rolando Hernandez , “Business Rules are the Key to CRM and One-to-One Personalization”, Business Rules Journal, URL: www.brcommunity.com/b064.php

[9]  Gerard Ellis, Robert Levinson, Peter J. Robinson: “Managing complex objects in Peirce.” International Journal of Human-Computer Studies 41(1-2): 109-148 (1994)

[10]  Gerard Ellis: “Compiling Conceptual Graphs.” IEEE Transactions on Knowledge and Data Engineering 7(1): 68-81 (1995)

[11]  “Cyclomatic Complexity” URL: en.wikipedia.org/wiki/Cyclomatic_complexity

[12]  “Folksonomies” URL: en.wikipedia.org/wiki/Folksonomy

[13]  R. Guha, Rob McCool and Eric Miller, “Semantic Search”, The Twelfth International World Wide Web Conference (2003). URL: www2003.org/cdrom/papers/refereed/p779/ess.html

 
 

# # #