GB2374690A

GB2374690A - Method for comparing quotes from different vendors

Info

Publication number: GB2374690A
Application number: GB0128770A
Authority: GB
Inventors: Robert Mark Pilkington; Paul Edwards
Original assignee: EBBON DACS Ltd
Current assignee: EBBON DACS Ltd
Priority date: 2000-11-30
Filing date: 2001-11-30
Publication date: 2002-10-23
Also published as: EP1344174A2; GB0029287D0; AU2002222116A1; GB0128770D0; WO2002044964A3; WO2002044964A2

Abstract

An article ordering system for use in a complex purchasing process having a plurality of stages is described. The system comprises request generation means for creating a user-determined article request, the request comprising a multi-dimensional data specification regarding the features of the article. Communications means are also provided which are arranged to transmit the request to one or more user-specified vendors via a wide area network and to receive multi-dimensional data responses from the one or more vendors. Ranking means rank the responses in order of the degree to which they match the request. The ranking means is configurable by the user to determine the weighting attributable to different features of the article for effecting the ranking. The system also comprises display means for presenting the ranked responses to the user for selection. The display means is arranged to indicate individual feature matching results for each of the requested features of the article such that the user is able to determine whether a lower ranked response is more suitable for selection due to a change in importance of one or more features.

Description

- 2374690

I RO TS RELATING TO O MON SYSTEMS

Field of the Invention

5 The present invention concerns improvements relating to information systems and more particularly, though not exclusively to a process management system for use in enquiring, ordering and tracking of a vehicle from a contract hire company via a dealership to an end user. The present invention also concerns a novel Graphical User Interface for use in the process. Background of the Invention,

The management of a complicated purchasing process, such as a new car purchase by an individual via a contract hire company, is a complex task because of the many factors and 15 variables which are involved and the lengthy tLme scale for completion a transaction from order to delivery. Such processes become even harder to manage when there are multiple individuals involved (as purchasers) for each vendor.

These types of processes have in the past been carried out largely manually using pen and 20 paper and have relied on acquired knowledge of the people involved in the process. In recent years, stock control systems have been developed to assist in the management of part of the process partichlarIy-from an accounting point of view. However, these systems have been wholly directed to providing information for the vendor and have been on-site local system that assist in the running of that vendor's business. Purchasers or even contract hire 25 companies wishing to see how their order is progressing have to contact the vendor in order for them to access their local system for a status check. Management of the complex supply chain using these systems, in particular keeping the current status of the order within the chain is labour intensive and, in particular, requires a significant amount of training for the operator to determine what the current status is ofthe order from the date presented to them.

Contact hire companies, as purchasers, deal with vast volllTnes of these complicated purchase processes for articles in the course of their business. The articles themselves are

relatively costly and as such any small savings made on each article can have a sigolficant overall cost saving to the company. In view of this, purchasers will often obtain quotations from many different vendors for price, availability and specification matching. If a contract

hire company wishes to obtain quotations from a plurality of vendors, each one of those 5 vendors has to be contacted separately and a detailed specification for the complicated

purchase has to be specified. As previously stated, many vendors have a manual system which relies on the knowledge of the vendor. For those vendors who have some sort of automated process, the specification of the article to be purchased has to be created which

will be in a format specific to their system. If the purchaser is required to specify exactly 10 what they require in a free format, then there can be inaccuracies in the request as the purchaser may not know about all of the selectable features of the article being purchased.

Where the purchaser can select vendor-presented options to create a specification, there can

also be problems. This is because most vendors have different systems for management of their stock, and so the creation of different specifications may be required in order to obtain

15 several quotations for the same article. This gives rise to another problem in that the different systems may not have equivalent specifications or the latest up-to-date

specification for the same article and hence the generated quotation prices may not truly

reflect an actual like-for-like comparison.

0 It is desired to overcome or substantially reduce at least some of the above-descn ed problems. Summary of the Invention

25 According to one aspect of the present invention there-is provided an article ordering system for use in a complex purchasing process having a plurality of stages, the system comprising: request generation means for creating a user-determined article request, the request comprising a multidimensional -data specification regarding the features of the article;

communications means arranged to transmit the request to one or more userspecified 30 vendors via a wide area network and to receive multidimensional data responses from the one or more vendors; ranking means for ranking the responses in order of the degree to which they match the request, the ranking means being configurable by the user to

determine the weighting attributable to different features of the article for effecting the ranking; and display means for presenting the ranked responses to the user for selection, the display means being arranged to indicate individual feature matching results for each of the requested features of the article such that the user is able to determine whether a lower 5 ranked response is more suitable for selection due to a change in importance of one or more features. The present invention provides significant advantages over the prior art. Firstly, by

centralizing the process for obtaining quotations, there is only a requirement to generate a 10 single request (enquiry) which is then sent to all the vendors. Another benefit of the central system is that use applied rules can be used for all responses to act as an automatic filter for completely unsuitable responses without the need for the purchaser to consider and then reject these quotations. However, the ranking of the quotations on user-defined criteria but which also enables the details feature matching to be seen enables a greater depth of analysis 15 to be Gamed out by the user when comparing quotations. User preferences can change and combinations of the multi-dimensional data which may not have been anticipated may arise which can, using the present invention, be given consideration because of the' displayed individual feature matching.

20 The term multi-dimensional data is intended ' for the purposes of this invention to mean complex data having at least three different data variables and preferably six or more data variables. The greater the number of variables the more complex the data becomes and hence the harder it is to process especially when comparisons between different multi-

dimensional data is requnred.

The term complex purchasing process is intended to mean a purchasing process which can take months to complete which typically has several distinct stages and is of a sufficient value to make tracking and status issues worthwhile.

30 Preferably, the request generation means comprises a database of standard multi-

dimensional data suitable for creating all different types of specifications of multi-

dimensional data for a class of article. This advantageously means that different requests do

not need to be created for different dealers. The standardization of the requesting information also ensures that less errors are created in the all important request specification.

5 The present invention extends to a method of ordering an article in a complex purchasing process having a plurality of stages, the method comprising: creating a user-determined article request, the request comprising a multi-dimensional data specification regarding the

features of the article; transmitting the request to one or more userspecified vendors via a wide area network and receiving multi-dimensional data responses from the one or more 10 vendors; ranking the responses in order of the degree to which they match the request, the ranking step employing user-determined weighting attributable to different features of the article for effecting the ranking; and displaying the ranked responses to the user for selection, the displaying step indicating individual feature matching results for each of the requested features of the multi-dimensionally specified article.

According to another aspect of the present invention there is provided a process monitoring system for use in monitoring a complex purchasing process having a plurality of stages, the system comprising: a request generation engine for generating a multi-dimensional data request and sending the same to one or more specified vendors; a status engine for creating a 20 status record in response to the creation of a user request; the status engine being responsive to inputs from the one or more vendors to update the status record to reflect the current sta-tus oFthe request tn the Complex purchasing process, and a time-st mp ng module arranged to time-stamp each event occurring in relation to the request which can change the status of the request, and to store a series of time stamps and event descriptors to create an 25 instant history of the complex purchasing process.

The creation of a history of events in this way advantageously enables detailed analysis of the complex process to be carried out at a later stage. This can assist in improving the process or analysing vendor performance.

The status engine is arranged to receive additional information regarding multi-

dimensionally specified article with a status update input during the complex purchase

process. The additional information can substantially enhance the recorded history of the complex process. For example a simple text comment explaining why a vendor was unsuccessfi 1 can assist in that vendor improving their next attempt at a quotation, perhaps by way of a greater discount for a particular vendor.

s The system is preferably arranged to make the history available to both the purchaser and the vendor. This enables self analysis of vendor performance to.be possible as well as analysis by the purchaser. AIso by making the status available to the purchaser at any time of day or night, there is better access to this information and the vendor need not be troubled 10 with statue enquiries.

The present aspect of the invention also extended to a method of monitoring a complex purchasing process having a plurality of stages, the method comprising: generating a multi-

dimensiona1 data request and sending the same to one or more specified vendors; creating a 15 status record in response to the creation of a user request; the creating step comprising updating the status record to reflect the current status of the request in the complex purchasing process in response to inputs from the one or more vendors; dine-stamping each event occurring in relation to the request which can change the status of the request, and creating an instant history of the complex purchasing process by storing a series of time 20 stamps and event descriptors According to another aspect of the present invention, there is provided a Graphical User Interface (GUI) for use by a purchaser in determining the current status of a complex purchasing process of a multidimensionally. specified article, the GUI comprising a two 25 dimensional array of graphical elements, each element corresponding to a request for a complex purchase and including a unique identifier to that purchase, wherein the positional relationship of the element within the array signifies its status along the process and each element is automatically movable within the array in response to an input of data from the purchaser or vendor which signifies a change in the status of the complex purchase process This is an exceptionally useful way of viewing many different multi-dimensional purchasing requests in a relatively simple manner which improves the way in which the user interacts s

with the system. The user can immediately recognise a particular request and note where it is in the complex process at a glance rather than having to analyse different fields of the

request. Also a snap shot of multiple requests being processed through the vendor's system can be viewed on a single screen.

Preferably the positional relationship to status is signified along a single dimension of the array. This simplifies the reading of the GUI at a glance even further as the status is merely signified by position along a line.

10 The GUI preferably further comprises means for selecting a complex purchasing process characteristic and means for filleting the graphical elements to retain those elements in the array that relate to the characteristic. This enables the user to focus on selected characteristics to make viewing of specific types of requests far more easier.

15 A system embodying the present invention, which has specific application to the field of

motor vehicle purchasing by contract hire companies thereinafter referred to as Leaselink), is designed to offer workilow and process efficiencies previously unavailable to both contract hire companies and car dealerships.

20 The system is easy to use. A GUI uses traffic light colours to prompt both dealers and contract hire companies about the urgency of tasks and responses aiding workflow. As each ........

task is entered into the system via the GUI, the system automatically updates all interested parties radically reducing paperwork, phone calls and misunderstandings. Any change of specification for a vehicle is immediately recorded, offering contract hire companies the

25 opportunity to proactively build an informed relationship with their customers.

Designed to simplify the complex purchasing procedure of the multidimensional article (vehicle) between contract hire companies and dealerships, Leaselink can be adapted to aid any complex, time-critical operations in other markets. One of the important elements of the 30 system is a noting and time stamping engine, which ensures accountability for all actions in the process.

Full vehicle tracking with automated, time-stamped documentation of all correspondence, slippages and real-time status reports leads to a series of advantages. For example: true proactive management of customer expectations regarding delivery; 5 detailed reports for each vehicle; reduced costs; reduced paperwork, reduced misunderstandings; useful feedback for de'alerships to fine-tune their offerings; and 10 records of persistent defaulters.

Vehicle configuration is preferably provided using standardized CAP Motor Research Data which is stored centrally on the system and this allows easy configuration and improved accuracy of requests. Dealer fitted accessories can also be entered using this central store of 15 information. A filtering system is provided with the GUI, which allows users to chunk 'tine information to just the information they wish to see and provides detailed analysis at a glance. The nature of the system means that mear ngful data is generated for analysis, planning and marketing. For the dealer, Leaselink provides a quick and efficient way to respond to contract hire company enquiries and to manage the vehicle from the time it is ordered through to the vehicle being delivered key to the system is the ability for the dealer to monitor their 25 effectiveness in both gaining and delivering orders against expectations.

The dealer sets up trading relationships' with contract hire companies and their end users via a simple maintenance routine. From there once an enquiry has been received the dealer simply responds to that enquiry only needing to alter discounts from the norm, where 30 applicable, and then offer a delivery date. The dealer can also offer alternative vehicles to any enquiry. This advantageously allows the dealer to sell Tom stock if appropriate rather than place a factory order for the vehicle.

Once the contract hire company has ordered the vehicle, the dealer moves the vehicle - through the workflow process updating the vehicles status as it goes. If the vehicle order changes the dealer can simply update the system with the change together with any financial 5 implications of that change. Once the dealer has received delivery instructions and subsequently delivered the vehicle the system can Pack the debts owed on vehicles from contract hire companies.

Leaselink offers enonnous benefits for dealers in responding both to contract hire 10 companies connected online and to those without electronic transfer systems. The system is sufficiently flexible to allow dealers to manually input data thereby providing a full view of the business conducted by the fleet department.

Leaselink is designed to provide process and workflow benefits to both the contract hire 15 company and car dealers by taking the time and effort out of the complex supply chain and ensures that both parties are kept up to date.

Leaselink provides an excellent customer service aid helping dealers to monitor their effectiveness in both gaining and delivering orders against expectations, ensuring high 20 customer service standards at all times.

A preferred embodiment of Me present invention will now be described by way of example with reference to the accompanying drawings.

i 25 Brief Description of the Drawings

Figure 1 is a schematic block diagram of a system embodying the present invention; Figure 2 is a schematic block diagram showing the Leaselink system module of Figure 1 in 30 detail; Figure 3 is a flow diagram showing the steps involved in implementing a method

embodying the present invention of ordering a vehicle in a complex purchasing process having a plurality of stages; Figure 4a is screen shot of a quote comparison screen generated by the Leaselink system of S Figure 2; Figure 4b is screen shot of a quote breakdown screen, showing 100% acceptance of an offered vehicle to a specification for the vehicle, generated by the Leaselink system of

Figure 2; Figure 4c: is screen shot of a quote breakdown screen, showing less than 100% acceptance of an offered vehicle to a specification for the vehicle, generated by the Leaselink system of

Figure 2; 15 Figure 5 is the flow diagram showing a continuation of the method shown in Figure 3, where steps involved in monitoring the complex purchasing process embodying the present invention are shown; Figure 6 is a screen shot of a GUI according to an embodiment of the present invention; Figures 7a, 7b and 7c are screen images of Tcard elements of the GUI of Figure 6 showing a one car icon, a two car icon and a rejected Tcard respectively, Figure 8a is a screen shot of a updating page generated from selecting a top portion of a 25 Tcard of the GUI of Figure 6; Figure 8b is a screen shot of a history page generated from selecting a bottom portion of a Tcard of the GUI of Figure 6; 30 Figure 9 is a screen shot of the GUI of Figure 6 showing the application of a filtering Unction to the displayed Tcards; and

Figure 10 is a screen shot of an on-line appraisal form for use with the process management procedure shown in Figure 5.

Detailed Description of the Preferred Embodunent of the Present Invention.

s A vehicle ordering system 10 incorporating a complex process management system 10 according to an embodiment of the present invention is shown in Figure 1. The system 10 is accessed by a contract hire company 12 and a plurality of car dealers 14 via a wide area network, in this embodiment, the Internet 16. The system 10 comprises a Web server 18 for 10 hosting a web site where information relating to the complex purchasing process can be stored, accessed and updated by the contract hire company 12 and the car dealers 14. The Web site is controlled by a Leaselink engine 20 which carries out the relevant processing of data to enable monitoring of the complex purchasing process as well as the process of ordering a vehicle. In order to carry out these functions, the engine 20 has access to a suite 15 of main databases 22 for dealers and contract hire companies as well as a standard new vehicle pricing and options database 24 (in this embodiment a CAP Motor Research database 24 is used). The CAP database 24 stores an industry standard listing of the complete specifications for all new vehicles (typically twenty tables each with a plurality of

data records having at least twenty fields of data).

The way in which the system 10 is used by the contract hire company 12 and the car dealers 14 is outlined below. The system 10 is accessed by the contract hire company 12 to create on behalf of a user, a request for a vehicle. The request is then transmitted to all specified car dealers 14. Each of the car dealers 14 respond with a detailed quotation for a vehicle 25 matching or nearly matching the specification. The responses from the car dealers are 14

matched to the specification and presented in ranked order to the contract hire company 12

for selection. Selection of a quote stark; a complex process management procedure whereby the process of converting a quotation into a firm order and its progression through to delivery of the vehicle to the user is monitored and reported on.

Whilst not shown explicitly in Figure 1, the system is arranged to enable a client of the contract hire company 12 to log on to the system 10 via the Intequet 16 and, subject to the

provision of a correct password, look at restricted information regarding the complicated purchase process.

Referring now to Figure 2, the Leaselinlc engine 20 comprises various modules for 5 performing specific tasks. A status module 30 controls the creation and updating of all status records relating to the various different purchase enquiries being handled by the system. The status module also is responsible for updating of the GUI (described later with reference to Figure 6) which is used by both the dealers and the contract hire-companies to check on the progress of and updating of any current enquiry.

The Leaselink engine 20 also comprises a request generation module 32 which is used to create new enquiries for vehicles. The request generation module relies heavily on accessing the CAP Motor Research database 24 which stores the required data to consistently describes all the details of motor vehicles for purchase.

A registration and management module 34 is provided to register each of the dealers 14 and the contract hire companies 12 that want to use the system 10. The dealers and contract hire companies enter in multidimensional configuration data, which is used by the system in its operation of providing quotations. The module 34 also enables management of this 20 configuration data such that settings and preferences can be changed.

The Leaseli engine 20 also comprises a report module 38 for generating reports of the systems activities. The report module 38 has a comprehensive reporting suite which works with online system alerts to deliver vital management information in report format covering 25 vehicle status based on dealer, end user company, franchise or driver information.

Finally, a time and date stamping module 40 is provided specifically for time stamping -each input/output event that occurs with the system 10. This module 40 is essential for the accurate functioning of the report generation module as most if not all of the reports 30 generated require time information to be included as a performance measure.

Referring now to Figure 3, a method 50 of ordering a vehicle using the system is now

described in detail. The method 50 commences with the car dealers 14 and the contract hire company registering at Step 52 with the Leaselink system 10. Apart from the basic registration reasons such as setting up specific user names and passwords, this enables the contract hire company to specify preferred ways of using the system for example, preferred 5 car dealers 14 from whom quotes can be requested. Also the contract hire company's specific rules for the matching process are stored at this stage such that it can filter out car dealers who do not meet its specific criteria, for example in speed of response. Also car dealers need to register to set up pre-arranged discounts which are available on a vehicle for a specific contract hire company, to also specify the list of contract hire companies which 10 the dealer already trades with and to specify who the actual people will be who have access to the system on behalf of the dealer. All these preferences and settings are stored in the databases 22 for the dealers and the contract hire companies.

Once the dealers and the contract hire company have been registered, the system 10 can be 15 used to generate quotations. This process commences at step 54 with a user at the contract hire company logging onto the system 10 and raising a-vehicle enquiry (request for a quotation). The vehicle enquiry contains multi-dimensional data as there are at least three but possibly thirty or forty variables that the user can select to specify the precise specification of the vehicle to be purchased. The specification is compiled using the CAP

20 Motor Research 24 database to ensure accuracy for the vehicle type and options required.

The enquiry typically also specifies a delivery date as another specification requirement.

Once the enquiry is raised, the purchaser decides -which of their approved dealers to send the enquiry to, based on franchise, location or both.

25 The creation of a vehicle enquiry triggers the start of the complex process management procedure, which sets up at Step 56, a status record for the vehicle enquiry and updates its status to 'Enquiry Received'. Also the record stores the time and date at which this event occurred for the purposes of building up a detailed history of events concerning the purchasing procedure.

The vehicle enquiry is then sent at Step 58 to all of the specified car dealers 14. If no car dealers have been specified, then the enquiry is sent to all of the contract hire company's

approved dealers 14.

The car dealers 14 are alerted to each new vehicle enquiry that is received. They generate one or more detailed responses, containing multidimensional data, for each vehicle they 5 consider matches or nearly matches the required specification. This not only includes the

multidimensional specification of the vehicle but also a quotation price and a delivery date.

Each of the responses is then sent back at Step 60 to the system 10 via the Internet 16. The time taken to respond to the enquiry can be a contract hire company parameter for judging whether the quotation will be progressed further.

On receipt of the responses, the system updates at Step 62 the stat-us record to 'Enquiry Responded'. Again the time and date of the event is also stored. At this stage if multiple car dealers are responding to a single enquiry, the system updates the status record to reflect this fact by attributing a multiple car icon rather than a single car icon to the status record as will 15 described in detail later.

Once the enquiries have been responded to with quotes from the car dealers 14, the system 10 ranks the quotations according to the contract hire company's predetermined matching criteria. Even if all of the user's specified features are present in several cars indicating a 20 100% match, there is ragbag of the quotations on other features such as price, availability, preferred dealers, speed of response etc. Otherwise, the degree to which the vehicle - specifica-tion' has been fulfilled is detetmined by the contract hire company's specified parameters for the matching process. These parameters include a weighting of various different specified features such that in the event of two quotes having the same number of 25 but different missing features, one can be ranked higher that the other. All the quotations for a single enquiry are shown side by side in ranked order to enable the user to compare and contrast the quotations. The presentation of these ranked results is discussed in detail later with reference to Figures 4a to 4c.

30 The user then selects at Step 66 a quotation that he or she wishes to progress. When a quote has been chosen, it is quickly turned at Step 68 into a confinned order with the dealer. This involves a notification being sent to the selected dealer notifying him of the selection and

ordering a vehicle in accordance with the specified quotation. The system10 then updates at Step 70 the status record for this enquiry to 'Customer Ordered' (recording the time and date of the event) and also ensures that vehicle enquiry representations of the status record which are viewable by each of the multiple dealers 14 is deleted from any unsuccessful 5 dealers screens but maintained on the single successful dealers screen. The multiple dealer icon remains the same to show that the enquiry was originally a multiple dealer enquiry although in an alternative embodiment, it would also be possible to change the multiple car icon into a single car icon at this point if desired.

10 The system 10 then automatically informs at Step 72 all other dealers that they have been unsuccessful and sets out a short message explaining why the successful quote was chosen.

The process of ordering a vehicle having been completed is then succeeded by a complex process management procedure, which monitors the status of the purchasing procedure through to delivery of the vehicle to the user and this is described in greater detail later.

Referring now to Figure 4a, an example of the ranked results of two quotations received from dealers 14 to a single enquiry is shown. Each ranked result shows a subset of all of the multi-dimensional data specified in the quotation to provide the user with an overview of the quotations. More specifically, in this embodiment, each quotation shows five items of 20 information, namely the name of the dealership, the quotation reference, the availability date, the total cost and the percentage match. However, each quotation line when selected - ge-nefafes anew screen showmg a more detailed breakdown ofthe quotation where all ofthe parameters ofthe quotation are shown.

25 Figure 4b is an example of such a detailed screen where there is 100 percent matching between the specified enquiry and the offered vehicle. A highly important feature of this screen is the individual matching between each item in the specified enquiry and each item in the received quotation. Each item of the enquiry has either a tick or a cross next to it to signify if this item has been met by the quotation. This enables the user to see exactly how 30 the matched percentage figure has been arrived at. In the present example, as there is 100 percent matching only green ticks are shown against the variable fields. However, Figure 4c

shows a quotation (shown in reduced format) where the trim does not match the specified

requirement and so a red cross is placed next to this field. In addition, the quotation in

Figure 4c also has additional features of a CD changer and a climate comfort windscreen included which were not specified in the requirements. These additional extras are readily identifiable because a blue plus sign is placed next to the corresponding field. In this way

5 the user is able to select the desired vehicle by considering all of the parameters such that if they have changed their mind on the importance of a feature they can still select that feature if needs be.

Referring now to Figure 5, the complex process management procedure 100 is described.

10 The process management system 10 ensures that the contract hire company 12 is kept informed at every point in the process using a combination of visual workflow progress and regular status updates, as the vehicle moves through the process to delivery. As each process takes place the system 10 notes who has carried out what action, at what time and on what date. The system 10 tracks the vehicle from a Dealership Pipeline, into Dealership Stock 15 through to PDI (Pre Delivery Inspection) until the dealer offers delivery.

More specifically, the complex process management procedure 100 commenced in the vehicle ordering process 60 shown in Figure 3 by the creation of a status record at Step -56 and was progressed by the further updating of the- status record at Steps 62 and 70. The 20 remained of the procedure 100 is shown in Figure 5. The receipt of a confirmed order from the system 10 makes the dealer 14 carry out a check at Step 102 to see whether the vehicle is - stock. If it -is, then the system ra is notified and the procedure 100 jumps forward to the carrying out of a PDI. If not then, an order is placed with the manufacturer with subsequent notification to the system 10 and this is checked at Step 104. If the order has been placed, 25 then the status record is updated at Step 106 to 'Dealership Pipeline' and the time and date of this event is recorded. Next checks are carried out to determine at Step 108 whether a car manufacturing date has been received and thereafter to deter rune at Step 110 whether the vehicle has been delivered to the dealer 14. Once the vehicle has been delivered, the system is notified and the status is updated at Step 112 to 'Dealership Stock' with the appropriate 30 time and date recordal.

Once in stock, the next stage is to carry out a PDI and this is checked at Step 114. On

completion of the PDI, the system is again notified and the status record is updated at Step 116 to 'PDI' with the appropriate time and date of this event being recorded. A check is then made at Step 118 to determine whether a delivery date has been offered. The status does not change from PDI until a delivery date has been offered. When it has been offered, this is 5 notified to the system 10 and the status record is updated at Step 120 to 'Delivery Offered'.

Again the time and date of this event are noted. Once delivery has been offered, the contract hire company can then give comprehensive delivery instructions to the dealership including any details of a return vehicle that may need to be collected (discussed below). The last stage of the process and hence the last condition of the status is to determine at Step 122 10 whether a delivery date has been arranged. If it has then the system is notified, the time and date logged and the status is updated at Step 124 to 'Delivery Arranged'. Completion of this stage of the process is notified to the system by the dealer and as a result the status record can be removed from further consideration.

15 Whilst not shown in Figure 5, the process can optionally be configured to have one final stage relating to delivery of the vehicle and receipt of a retum vehicle. This part of the procedure 100 would involve determining whether-there was a return vehicle to collect and if so retrieving its details for the contract hire company 12 (or the relevant database 22 if it was bought via the present embodiment). The vehicle would be collected and appraised 20 using an on-line appraisal form such as that shown in Figure 10. The dealer would confirm receipt of the return vehicle and the appraisal form would be submitted back to the contract hare -comp-any 12 for their records and for determmin-g whether there is any damage charge to be passed onto the user.

25 Furthermore, it is to be appreciated that when a dealer updates the status of an order, typically further information is sent to the system which is relevant to that particular stage and that information is then used to enhance the information regarding that particular enquiry/purchase. For example, when the dealer sends notification that the vehicle is in stock, he also sends information regarding the factory order number, the chassis mlrnber, the 30 key number, an engine number, a radio security code, a stock number, a registration number etc. and also confirms that the basic vehicle details are correct and that all of the factory fitted options are correct.

Referring now to Figure 6, there is shown a GUI 130 used in the complex purchasing management process described above. This is the main navigation screen used within the website of the system 10. The system functions are managed by using the blue buttons 132, 5 which are placed down the left-hand side of the screen 130. The blue horizontal menu of colons 134 provides a visual aid allowing the user to track an enquiry through the process from the initial enquiry stage to delivery of the vehicle across the screen from left to right.

Each column 134 represents a distinct stage ofthe complex purchasing process.

10 Figure 6 shows the main screen which shows an array of enquiry status elements 136 (hereinafter referred to as Tcards). Each Tcard 136 represents a single enquiry and its position within the array signifies its status along the purchasing procedure.

The blue buttons 132 have various navigation functions which enable navigation around the 15 Web site but which also enable the creation of a vehicle enquiry on the system 10 on behalf - of a contract hire company not connected online p;tnafter referred to as a local contract hire company), for example. Also reports can be generated and messages sent-to any:of the contract hire companies 12 or dealers 14. There are release notes for the invention software and a help function.

As mentioned above, each column 134 represents a stage in the complex purchasing process. More specifically, regarding the 'EIiquiry Received' column 134, when a contract hire company 12 sends an enquiry to a dealership 14, the Tcard 136 for that enquiry appears in this collard. If any enquires are added on behalf of a local contract hire company, these 25 Tcards 136 also appear in this column. When the dealership responds to an enquiry, i.e. by making an offer to the contract hire company, the Tcard 136 is moved into the 'Enquiry Responded' column 134. The 'Customer Ordered' column shows the vehicles that have been ordered by the customer. An online contract hire compa y may accept your quote for an enquiry and move the Tcard 136 into this column. If the enquiry were made by a local 30 contract hire company, the dealership would have to move the Tcard and update the details on their behalf. The 'Dealership Pipeline' column shows the vehicles that are in the order process but which have not yet reached the dealer 14. Once the vehicle has reached the

dealership the Tcard 136 is moved into this column 134 to represent vehicles that are physically in stock at the dealership. The PDI (PreDelivery Inspection) column 134 is used to signify that a vehicle is in the PDI process at the dealership. Similarly, once the PDI has been completed, and delivery of the vehicle has been offered to the contract hire company, 5 then the Tcard of that enquiry is moved into this column to signify that this colon 134 shows the vehicles that are ready to be offered for delivery to the customer. The final column 134 is the delivery arranged column into which Tcards 136 are moved to indicate they are simply pending an arranged delivery date.

10 Under each col rm heading 134, there are a column of Tcards 136 with one or two car icons 138 displayed in them in the top half of the Tcard 136 and a bottom half 140 containing text.

Each Tcard 136 can also have one or more supplementary icons 142 representing incoming notes (icon 144), outgoing notes (icon 146), change in Anticipated Delivery To Customer (ADTC) (icon 148) and follow up calls (icon 150) which identifies any enquiry which 15 requires a follow up can today.

A Tcard 136 with a one-car icon 138 represents an enquiry placed on the system by a -. contract hire company that went to one dealership only. Once the enquiry has become -an order, the Tcard win stay with only one car icon. Additionally, enquiries placed by the 20 dealership on behalf of a local contract hire company will also show only a one-car icon 138 on the Tcard 136. A Tcard 136 with a t vo-car icon 138 represents an enquiry placed on the system 10 by a con ct Are company -to two or More dealers 14. Once the enquiry has become an order, the Tcard will All have a two car icon 138 though will only be viewable by the dealer 14 who has secured the order and the contract hire company 12 placing the 25 enquiry.

For the GUI 130 viewed by a dealer 14, the first line of text 140 in the lower part of the Tcard 136 is the name of the person who placed the enquiry. The second line of text 140 is the name of the contract hire company who placed the enquiry, or in the case of local 30 contract hire company, the name of the contract hire company on whose behalf the enquiry was made. The last line of text 140 is initially the enquiry reference, but once a car has been ordered, this changes to the order reference.

For the GUI 130 viewed by a contract hire company 12, the second line is the name of the dealership 14 rather than the contract hire company 12. Otherwise, the Tcards 136 for both the dealer 14 and the contract hire company 12 are the same.

s The system has a timing facility that allows you to set a tone scale within which the enquiry has to be dealt with. For example when an enquiry is received, a response has to be sent back to the contract hire company within an hour.

10 The timing is illustrated on the GUI 130 with the use of a traffic lights process. For example, an enquiry is received and the dealer has to respond to the enquiry within the hour. When the dealer receives the enquiry the colour of the car icon will be green and at the top of the Enquiry Received' column 134, it will then turn to amber fifty minutes after the enquiry - was received, it will finally turn to red when the enquiry has been there for over an hour.

When the contract hire company (user) has accepted a quotation, the GUI 130 for dealer 14 who was not selected shows that enquiry as a rejected enquiry. This is illustrated in Figure 7c as a Tcard with a red cross 152 to illustrate that the contract hire company 12 has decided to accept an offer made by another dealership 14, and has therefore rejected that dealer's.

Referring now to Figures 8a and 8b, the two types of screens which can be generated by sedection of the car icon 138 of a Tcard or the text lie of a Tcard are now described.

Selection of the car icon 138 generates a look up screen showing the details of the enquiry together with updating details. Depending on which column 134 the Tcard 136 is, different 25 look up screens will be generated. The example shown in Figure 8a is of an updating procedure for a Tcard 136 in the Dealership Pipeline column 134 which is to be moved to the Dealership Stock column 134. More specifically, it can be seen that the basic information regarding the order is present in the left-hand side of the screen under a look up heading. In addition, in a right-hand side column headed New Details, there are several 30 blank fields for additional information which is required by the system, such as chassis

number, engine number, registration number etc. The only requirement is for the chassis number to be entered as completion of the other fields is not mandatory. However, the

dealer is encouraged to enter as much information as possible. Submission of this form by pressing an apply button on the screen, automatically causes the Tcard 136 of this enquiry to be moved into the Dealership Stock column 134 ofthe GUI 130.

5 If a user from the dealership 14 or contract hire company 12 selects the bottom half 140 of the Tcard 136 which displays text, then a history screen is generated as shown for example in Figure fib. The history screen sets out the total time lapsed since the enquiry was generated, and other basic information such as current stage of the process, expected delivery date and chassis number, for example. The historical performance 'characteristics 10 are set out in the lower section of the history screen. More specifically, there is a vehicle status history which sets out all of the vehicle related events, a system generated history where each of the system generated events are logged, a contract hire company notes history and a dealership notes history. In this way, a detailed analysis of what has been happening during the complex purchasing procedure can be ascertained.

Referring now to Figure 9 a filtering feature of the GUI 130 is now described. The GUI 130 has a compound filter option provided via a filter bar 154 at the top of the screen which enables the GUI to selectively display filtered Tcards. This has particular application when the dealer 14 or contract hire company 12 has very many enquiries which it is handling at 20 the same time. The filter field allows the dealer to search for a particular enquiry, which

contains certain characteristics. For example, if he dealer 14 deals with a vast number of enqumes every' day end 'needs to find out which enquires have received an 'Incoming Note' the dealer can filter the home page GUI by Notes Attached Incoming and the GUI 130 filters the home page to display only the relevant enquiries (as shown in the Figure 9 example).

It is also possible having chosen a filter criteria, to enter another data field, such as a date

field, which would require entering of further details. This helps the system perform an

accurate search.

30 In many circumstances there will be a requirement to search on more than one criteria at any one time and the filtering Unction accommodates this by using simple AND logic functions between the filter criteria. For example, there could be a filter for ' Process Stage"=

Dealership Pipeline, where 'Incoming Notes" have been received. In this case, only Tcards that are in the Dealership Pipeline stage and have an incoming message icon will remain on the GUI screen 130.

5 The present embodiment also has a quick filter function. At the right hand end of the filter bar 154 are the four supplementary icons 144, 146, 148, 150 with numbers next to them indicating the numbers of Tcards 136 there are in the GUI array with that supplementary icon provided. Clicking on any of the supplementary icons automatically applies a filter to the Tcard in the GUI array only leavmg the Tcards which have the specific supplementary 10 icon which has been selected.

Having described a particularly preferred embodiment of the present invention, it is to be appreciated that the embodiment in question is exemplary only and that variations and modifications such as will occur to those possessed of the appropriate knowledge and sldils 15 may be made without departure from the Spirit and scope of the invention as set forth in the appended claims. For example, the present invention is not restricted to handling purchasing of vehicles, any multi-dimensionally specified article can be the subject of the present invention such as a new house or building which is being built to a detailed specification.

Furthermore, even though the present invention has been described in relation to a single 20 contract hire company, it is to be appreciated that the system is specifically designed to operate with multiple contract hire companies. In fact, it is when the system becomes heavily- used that its attn utes and advantages are most clearly seen.

It is also to be appreciated that the Dealership Pipeline is the longest stage ofthe purchasing 25 process and so in another embodiment of the present invention this stage of the process can have various other updateable stages. However, these do not affect the position of the Tcard within the array. Rather they simply change the history screen of the Tcard such that the user can have a more accurate idea of where the process has got to. For example the Dealership Pipeline stage can be sub divided into the following stages: FACTORY 30 ORDERED, UNCONFIRMED BUILD, CONFIRMED BUILD, RELEASED FROM

FACI ORY, IN TRANSIT TO UK, IN TRANSIT TO DEALER, DEALER TRANSFER

Claims

1. An article ordering system for use in a complex purchasing process having a plurality of stages, the system comprising: 5 request generation means for creating a user-determined article request, the request comprising a multi-dimensional data specification regarding the features of the article;

communications means arranged to transmit the request to one or more user specified vendors via a wide area network and to receive multidimensional data responses from the one or more vendors; 10 ranking means for ranking the responses in order of the degree to which they match the request, the ranldng means being configurable by the user to determine the weighting attributable to different features of the article for effecting the ranking; and display means for presenting the ranked responses to the user for selection, the display means being arranged to indicate individual feature matching results for each of the 15 requested features of the article such that the user is able to determine whether a lower ranked response is more suitable for selection due to a change in importance of one or more features.

2. A system according to Claim 1, wherein the- request generation means comprises a 20 database of standard multi-diTnensional data suitable for creating all different types of specifications of multidimensional data for a class of article.

3. A system according to Claim 2, wherein the database comprises a CAP database.

25

4. A system according to any of Clowns 1 to 3, wherein the communications-means is arranged to support communications with the user to create a request and to provide the ranked responses to the request.

5. A system-according to any preceding claim, wherein the ranicing means is arranged 30 to be configurable by a set of user-defined matching rules.

6. A system according to Claim 5, wherein- the user-defined matching rules are -Z, 7

arranged to specify maximum response times for the vendors.

7. A system according to any preceding claim, wherein the display means is arranged to display a percentage figure indicating the percentage matching of the multi-dimensional 5 data of the response specification to that of the request specification.

8. A system according.to any preceding claim; wherein the display means is arranged to display a subset of the multidimensional data of each response received back from each vendor for comparisons purposes and to enable a more detailed analysis of the matching 10 between the request specification and the response specification on selection of one of the

responses.

9. A system according to any preceding claim, wherein the display means is arranged to indicate individual feature matching results for each of the requested features of the article 15 by use of simple tick and cross symbols against each of the displayed features.

10. A system. according to any preceding claim, further comprising acceptance means arranged to receive an acceptance of one of the quotations.and for converting the quote acceptance. into an order for the article.

-

11. A system according to Claim 10, wherein the acceptance means is arranged to .. transmit the order to the vendor of the selected quotation and to notify any other vendors whose quotations have not been selected of the unsuccessful quotations.

25

12. A process monitoring system for use in monitoring a complex purchasing process having a plurality of stages, the system comprising: a request generation engine for generating a multi-dimensional data request and sending the same to one or more specified vendors; a status engine for creating a status record in response to the creation of a user À 30 request; the status engine being responsive to inputs from the one or more vendors to update the status record to reflect the current status of the request in the complex purchasing process; and

a time-stamping module arranged to time-stamp each event occurring m relation to the request which can change the status of the request, and to store a series of time stamps and event descriptors to create an instant history of the complex purchasing process.

5

13. A system according to Claim 12, wherein the status engine is also responsive to inputs from the purchaser to update the status record to reflect the current status of the request in the complex purchasing process.

14. A system according to Claim 12 or 13, wherein the status engine is arranged to 10 receive additional information regarding multidimensionally specified article with a status update input during the complex purchase process.

15. A system according to any of Claims 12 to 14, wherein the additional information is a text message.

16. A system according to any of Claims 12 to 15, wherein the additional information is article-specific information required for subsequent use of the article.

17. A system according to any of Claims 12 to 16, wherein the system is arranged to 20 make the history available to both the purchaser and the vendor.

18. A Graphical User Interface (GUI) for use by a purchaser in determining the current status of a complex purchasing process of a multi dimensionally specified article, the GUI comprising a two-dimensional array of graphical elements, each element corresponding to a 25 request for a complex purchase and including a unique identifier to that purchase, wherein the positional relationship of the element within the array signifies its status along the process and each element is automatically movable within the array in response to an input of data from the purchaser or vendor which signifies a change in the status of the complex purchase process.

19. A GUI according to Claim 18, wherein the unique identifier comprises the name of purchaser.

20. A GUI according to Claim 18 or 19, wherein the unique identifier comprises the name of purchaser, wherein the unique identifier comprises a unique identification number.

5

21. A GUI according to Claims 19 or 20, wherein each graphical element also includes the name ofthe vendor.

22. A GUI according to any of Claims 18 to 21, wherein the positional relationship to status is signified along a single dimension ofthe array.

23. A GUI according to any of Claims 18 to 22, wherein the GIJI is arranged to display a plurality of graphical elements representing different requests for complex purchases, and the number of purchases at a given stage in the complex process is signified along a dimension transverse to the single status determining dimension of the array.

24. - A GUI according to any of Claims 18 to 23, wherein at least some of the graphical elements comprise an icon representing a single vendor associated with a single request.

25. A GUI according to any of Claims 18 to 24, wherein at least some of the graphical 20 elements comprise an icon representing multiple possible vendors associated with a single request.

26. A GUI according to any of Clanns 18 to 25, wherein at least some of the graphical elements in the array are each an active element, the selection of which causes an 25 information screen regarding the corresponding muld-dimensionally specified article to be displayed.

27. A GUI according to Claim 26, wherein each active graphical element has a plurality of different active regions, each active region causing, on selection, a different information 30 screen to be displayed.

28. A GUI according to Claim 26 or 27, wherein the information screen comprises a

history of the complex purchasing process.

29. A GUI according to Claim 26 or 27, wherein the information screen comprises a full specification ofthe multi-dimensionally specified article.

30. A GUI according to Claim 26 or 27, wherein the infonnation screen comprises a form for input of information by the vendor regarding the multi nensionally specified article and/or its complex purchasing process.

10

31. A GUI according to any of Claims 18 to 30, wherein at least one of the graphical elements comprises a notes icon indicating that there are notes attached to the graphical element from the purchaser to the vendor.

32. A GUI according to any of Claims 18 to 31, wherein at least one of the graphical 15 elements comprises a date icon indicating that there has been a change in the specified date of completion ofthe complex purchasing process.

33 A GUI according to any of Claims 18 to 32, wherein at least one of the graphical elements comprises a message icon indicating that is- a message attached to the graphical 20 element from the vendor to the purchaser.

34.- - A GUI according to any of Cfaims 18 to 33, further comprising means for selecting a complex purchasing process characteristic and means for filtering the graphical elements to retain those elements in the array that relate to the characteristic.

35. A GIJI according to Claim 34 as dependent on any of Claims 31 to 33, wherein the selecting means comprises a graphical representation of each of the notes, dates and message icons, the selection of one of the represented icons filtering all of the responses to retain all elements comprising the selected icon.

36. A GUI according to Claim 34 or 35, wherein the selecting means is arranged to select multiple characteristics and the filtering means is arranged to retain all elements 7 C>

relating to the selected multiple characteristics.

37. A GIJI according to any of Claims 18 to 36, wherein at least some of the graphical elements have an associated predetermined response time limit and are arranged to change 5 their displayed appearance as the time from posting the graphical element on the array approaches the predetermined limit of the response time.

38. A GIJI according to Claim 37, wherein the graphical element is arranged to change colour as the predetermined response time limit is approached.

39. An article ordering system as claimed in any of Claims 1 to 11, further comprising a process monitoring system as claimed in any of Claims 12 to 17.

40. An article ordering system as claimed in any of Claims 1 to 11, further comprising a 15 GUI as claimed in any of Claims 18 to 38.

41. A process monitoring system as claimed in any of Claims 12 to 17, further comprising a GUI as claimed in any of Claims 18 to 38.

20

42. A method of ordering an article in a complex purchasing process having a plurality of stages, the method comprising: -' - creating i userdetermmed article request, the request comprising a multi-

dimensional data specification regarding the features of the article;

transmitting the request to one or more user-specified vendors via a wide area 25 network and receiving multi-dimensional data responses from the one or more vendors; ranldug the responses in order of the degree to which they match the request, the ranking step employing user-determined weighting attributable to different features 'of the article for effecting the ranking; and displaying the ranked responses to the user for selection, the displaying step 30 indicating individual feature matching results for each of the requested 'features of the multi-

dimensionally specified article.

À-43. method of monitoring a complex purchasing process having a plurality of stages, the method comprising: generating a multi- dvmensional data request and sending the same to one or more specified vendors; 5 creating a status record in response to the creation of a user request; the creating step comprising updating the status record to reflect the current status of the request in- the complex purchasing process in response to inputs from the one or more vendors; time-stamping each event occurring in relation to the request which can change the status ofthe request, and 10 creating an instant history of the complex purchasing process by storing a series of time stamps and event descriptors.

^- (z 13/