AU2002220860A1

AU2002220860A1 - Improvements relating to event process handling

Info

Publication number: AU2002220860A1
Application number: AU2002220860A
Authority: AU
Inventors: Graham Barker; Robert Mark Pilkington
Original assignee: EBBON DACS Ltd
Current assignee: EBBON-DACS Ltd
Priority date: 2000-11-30
Filing date: 2001-11-30
Publication date: 2002-06-11
Also published as: JP2004520644A; US20050102185A1; CA2428605A1; GB0029226D0; EP1340183A2; WO2002044963A3; WO2002044963A2; WO2002044963A9

Description

IMPROVEMENTS RELATING TO INFORMATION SYSTEMS

Field of the Invention

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 variables which are involved and the lengthy time 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 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 particularly 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 systems that assist in the running of that vendor's business. Purchasers or even contract hire 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 of the order from the data presented to them.

Contract hire companies, as purchasers, deal with vast volumes 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 significant 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 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 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 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.

It is desired to overcome or substantially reduce at least some of the above-described problems.

Summary of the Invention

( 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 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 multi-dimensional 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 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 centralising the process for obtaining quotations, there is only a requirement to generate a single request (enquiry) which is then sent to all the vendors. Another benefit of the central system is that user 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 to be carried 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.

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 multidimensional data is required.

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.

Preferably, the request generation means comprises a database of standard multidimensional data suitable for creating all different types of specifications of multidimensional data for a class of article. This advantageously means that different requests do not need to be created for different dealers. The standardisation of the requesting information also ensures that less errors are created in the all important request specification.

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 user-specified vendors via a wide area network and receiving multi-dimensional data responses from the one or more 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 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 status of the request in the complex purchasing process; and a time-stamping 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 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 unsuccessful can assist in that vendor improving their next attempt at a quotation, perhaps by way of a greater discount for a particular vendor.

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. Also 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 with status 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 multidimensional data request and sending the same to one or more specified vendors; 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 of the request, and creating an instant history of the complex purchasing process by storing a series of time 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 multi-dimensionally specified article, the GUI comprising a two- 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 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.

The GUI preferably further comprises 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. This enables the user to focus on selected characteristics to make viewing of specific types of requests far more easier.

A system embodying the present invention, which has specific application to the field of motor vehicle purchasing by contract hire companies (hereinafter referred to as Leaselmk), is designed to offer workflow and process efficiencies previously unavailable to both contract hire companies and car dealerships.

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 opportunity to proactively build an informed relationship with their customers.

Designed to simplify the complex purchasing procedure of the multi-dimensional article (vehicle) between contract hire companies and dealerships, Leaselmk can be adapted to aid any complex, time-critical operations in other markets. One of the important elements of the 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; • detailed reports for each vehicle;

• reduced costs;

• reduced paperwork;

• reduced misunderstandings;

• useful feedback for dealerships to fine-tune their offerings; and • records of persistent defaulters.

Vehicle configuration is preferably provided using standardised 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 information. A filtering system is provided with the GUI, which allows users to chunk the information to just the information they wish to see and provides detailed analysis at a glance.

The nature of the system means that meaningful data is generated for analysis, planning and marketing.

For the dealer, Leaselmk 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 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 applicable, and then offer a delivery date. The dealer can also offer alternative vehicles to any enquiry. This advantageously allows the dealer to sell from 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 implications of that change. Once the dealer has received delivery instructions and subsequently delivered the vehicle the system can track the debts owed on vehicles from contract hire companies.

Leaselmk offers enormous benefits for dealers in responding both to contract hire 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.

Leaselmk is designed to provide process and workflow benefits to both the contract hire 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.

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

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

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 Leaselmk system module of Figure 1 in 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 Leaselmk system of 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 Leaselmk 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 Leaselmk system of Figure 2;

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 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;

Figure 9 is a screen shot of the GUI of Figure 6 showing the application of a filtering function 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 Embodiment of the Present Invention.

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 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 Leaselmk 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 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 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 starts 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 Internet 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 Leaselink engine 20 comprises various modules for 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 multi-dimensional configuration data, which is used by the system in its operation of providing quotations. The module 34 also enables management of this configuration data such that settings and preferences can be changed.

The Leaselink 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 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 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 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 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 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 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.

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 multi-dimensional data, for each vehicle they consider matches or nearly matches the required specification. This not only includes the multi-dimensional 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 status 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 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 100% match, there is ranking of the quotations on other features such as price, availability, preferred dealers, speed of response etc. Otherwise, the degree to which the vehicle specification has been fulfilled is determined 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 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.

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 confirmed 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 system 10 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 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.

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 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 generates a new screen showing a more detailed breakdown of the quotation where all of the parameters of the quotation are shown.

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 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 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. 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, 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 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 in stock. If it is, then the system 10 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, 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 determine 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 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 'PDF 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 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 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.

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 return 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 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 hire company 12 for their records and for determining whether there is any damage charge to be passed onto the user.

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 number, the 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, which are placed down the left-hand side of the screen 130. The blue horizontal menu of columns 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 of the complex purchasing process.

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 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 (hereinafter 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 'Enquiry 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 column. If any enquires are added on behalf of a local contract hire company, these 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 company may accept your quote for an enquiry and move the Tcard 136 into this column. If the enquiry were made by a local 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 (Pre-Delivery 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, then the Tcard of that enquiry is moved into this column to signify that this column 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.

Under each column 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 requires a follow up call 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 will stay with only one car icon. Additionally, enquiries placed by the 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 two-car icon 138 represents an enquiry placed on the system 10 by a contract hire company to two or more dealers 14. Once the enquiry has become an order, the Tcard will still 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 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 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.

The system has a timing facility that allows you to set a time 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.

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 selection of the car icon 138 of a Tcard or the text 140 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 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 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 of the GUI 130.

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 8b. 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 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 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 enquiries every day and 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.

In many circumstances there will be a requirement to search on more than one criteria at any one time and the filtering function 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 " coming 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.

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 leaving the Tcards which have the specific supplementary 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 skills 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 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 attributes and advantages are most clearly seen.

It is also to be appreciated that the Dealership Pipeline is the longest stage of the purchasing 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 ORDERED, UNCONFIRMED BUILD, CONFIRMED BUILD, RELEASED FROM FACTORY, 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: 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 multi-dimensional 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 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 database of standard multi-dimensional data suitable for creating all different types of specifications of multi-dimensional data for a class of article.

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

4. A system according to any of Claims 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 ranking means is arranged 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 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 data of th 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 multi-dimensional data of each response received back from each vendor for comparisons purposes and to enable a more detailed analysis of the matching 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 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.

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 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 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 instant history of the complex purchasing process.

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 receive additional information regarding multi-dimensionally 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 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 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.

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

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

23. A GUI according to any of Claims 18 to 22, wherein the GUI 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 elements comprise an icon representing multiple possible vendors associated with a single request.

26. A GUI according to any of Claims 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 information screen regarding the corresponding multi-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 screen to be displayed.

28. A GUT 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 of the multi-dimensionally specified article.

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

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 elements comprises a date icon indicating that there has been a change in the specified date of completion of the 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 element from the vendor to the purchaser.

34. A GUI according to any of Claims 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 GUI 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 relating to the selected multiple characteristics.

37. A GUI 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 their displayed appearance as the time from posting the graphical element on the array approaches the predetermined limit of the response time.

38. A GUI 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 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 GUT as claimed in any of Claims 18 to 38.

42. 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 multidimensional data specification regarding the features of the article; transmitting the request to one or more user-specified vendors via a wide area network and receiving multi-dimensional data responses from the one or more 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.

43. A method of monitoring a complex purchasing process having a plurality of stages, the method comprising: generating a multi-dimensional data request and sending the same to one or more specified vendors; 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 of the request, and creating an instant history of the complex purchasing process by storing a series of time stamps and event descriptors.