The present invention relates to the field of fleet management. In particular, the present invention relates to the management of a plurality of vehicles comprising a fleet so that informed decisions can be made as to the deletion of vehicles from the fleet.
Companies that maintain a fleet comprising numerous vehicles are faced with a daunting challenge with respect to how to effectively track and cost manage the fleet. Among the difficult questions that face fleet managers include which vehicles to delete from the fleet and when to do so. This is a difficult task for companies that maintain a relatively small fleet of vehicles much less for companies (such as the assignee of the present invention) that maintain a large fleet of vehicles.
For example, at any given time, the assignee of the present invention maintains a fleet of approximately 650,000 vehicles (including rental vehicles and leased vehicles), a number that is constantly growing with time. Not only does this fleet population represent a vast number, but it also must be noted that this fleet is divided into numerous geographically separated subfleets, each subfleet having its own characteristics that affect management decisions relating thereto, thereby further complicating the fleet management process. To effectively operate a rental vehicle business, the rental company must effectively plan and cost manage the influx and outflux of rental vehicles from the fleet. On the basis of value depreciation, rental vehicles will need to be timely deleted from the rental fleet and shifted to the used vehicle sales (remarketing) market.
Toward this end, the assignee of the present invention had previously developed and implemented a fleet planning system that allowed users to enter residual values for vehicles in the fleet at the year, make, model, and series (YMMS) level (wherein “series” specifies a particular series, body style, version, etc. of a particular YMM), determine the cost going forward (CGF) for each YMMS based on the user-entered residual value estimations, and designate a total number of vehicles within a particular YMMS that are to be deleted from the fleet. While this system certainly provided value and efficiency to the fleet planning process, room for improvement still existed. For example, this fleet planning system did not provide any historical sales data about fleet YMMSs to users to help guide their residual value estimations. Accordingly, users had only their own business sense to rely upon when estimating a residual value for a fleet YMMS. Further still, users were unable to schedule specific vehicles for deletion from the fleet and were instead provided only the ability to designate a total number of vehicles within a YMMS that were to be deleted.
Additionally, the assignee of the present invention also previously developed and implemented a fleet data warehouse application that allowed users to submit queries to a fleet database and receive (in response to the queries) simplified arithmetic averages of raw data for past vehicle sales. However, with this previous data warehouse application, due to the nature of these simplified raw data averages, users were unable to efficiently compare year-to-year and month-to-month trends in sales price because comparing these different average values was similar to comparing apples to oranges.
In an effort to improve upon previous efforts at fleet management, the inventors herein have developed a system that analyzes historical sales data for vehicles that were previously sold as used vehicles, normalizes this historical sales data to a particular value for a parameter common to the historical sales, and presents the results derived from this normalization to users. By providing users with detailed historical sales data drawn from previous sales of vehicles, users are now able to take advantage of normalized historical sales data to temper their own business judgments as to how a particular vehicle type's residual value can be accurately estimated, which the inventors believe will enable users to more accurately forecast future residual values. Because residual value estimations are one of the driving forces behind determining how many of a particular vehicle type are to be deleted from a fleet, accuracy in residual value estimation is highly important in the fleet management process.
Preferably, the historical sales data analysis provided by the present invention for a particular vehicle type (such as YMMS) is based on, at least in part, the actual sales prices for previously sold vehicles of the same or similar YMMS and the actual odometer reading for those vehicles at the time of sale. From these data values, a calculation is made as to what the average odometer reading was for those vehicles at their times of sale. Thereafter, each vehicle's sale price is preferably normalized to this average odometer reading such that each vehicle is assigned an adjusted sales price that matches what that vehicle would have been expected to sell for if that vehicle had the average odometer reading on its odometer at the time of sale. In the U.S. and other countries that use miles as the unit of measure for distances traveled by vehicles, it is preferred that the odometer readings be expressed in terms of mileage. For countries that use kilometers as the appropriate unit of measure, it is preferred that the odometer readings be expressed in terms of kilometers. To aid in this normalization process, a table that relates vehicle value to a time of sale odometer reading, referred to herein in a preferred U.S. embodiment as a cost per mile table, is preferably used. These normalized sales prices can then be averaged together to determine, for vehicles within a YMMS that is the same or similar to a user-selected YMMS, an average sales price normalized to an average mileage.
Also, to further provide the user with detailed historical sales data, this average mileage determination and sales price normalization are preferably performed on a per month basis such that the average mileage analysis for a particular month only covers the sales of vehicles within a same or similar YMMS that occurred in that particular month, with the year of sale effectively being disregarded. The sales price normalization and averaging are preferably performed per YMMS per month. Having done so, users can be provided with a data table that identifies for each month of any given year: (1) an average mileage for vehicles within a same or similar YMMS that were sold in that month and (2) an average normalized sales price for vehicles within each YMMS that were sold in that month. This historical data can be generated and displayed going back several years if desired by a practitioner of the present invention. Having historical sales values normalized to average mileages for the same or similar YMMSs sold in specific months allows users to easily compare year-to-year changes in YMMS sales price as well as month-to-month sales trends.
To aid the system in pooling historical sales data for a user-selected YMMS, a mapping program is preferably made available to users that allows users to group a plurality of previous year YMMSs (and possibly current year YMMSs) to a particular current year YMMS. Sales data for these grouped YMMSs will then be analyzed in accordance with the techniques described above to generate the average mileages and the average normalized sales prices. The YMMS group corresponding to a user-selected YMMSs would thus comprise the user-selected YMMS and any other YMMS(s) deemed to be similar to the user-selected YMMS. An example will help illustrate this mapping process. To perform a historical sales analysis for a hypothetical YMMS of a 2004 MKE MDL SER, the system will preferably perform the above-described historical sales analysis for the 2003 MKE MDL SER, the 2002 MKE MDL SER, and so on for previous vehicles that are deemed by the user to be sufficiently similar to the user-selected YMMS. To enable this historical analysis, it is preferred that such older YMMSs (the 2003 and older MKE MDL SERS) be grouped with the current YMMS (the 2004 MKE MDL SER). Once the YMMS are so grouped into a common YMMS group, the software of the present invention will know which sales data stored in the database should be accessed to perform the historical analysis.
The data table described above for normalized historical sales data for each month applicable to a user-selected YMMS is preferably displayed by the system to users via a page on the user's computer monitor. This page preferably also allows the users to enter residual value estimates for that YMMS for the current month and a plurality of future months. Once the user enters these residual value estimates, the system can perform a CGF analysis on the user-entered residual values. This CGF analysis preferably generates and displays a CGF for the user-selected YMMS.
To flag vehicles for deletion, at least partially on the basis of the user's analysis of these CGF values, the system preferably provides the user with the ability to access a list of specific vehicles within a YMMS to which the CGF analysis pertains, each vehicle preferably being listed along with its current mileage, wherein the list allows the user to select specific vehicles for deletion. Upon selection by the user of one or more specific vehicles for deletion from the list, a message can be sent to a branch manager or other person in charge of a selected vehicle that the vehicle can be timely transferred out of the rental fleet and into the used vehicle (remarketing) market. Alternatively, a flag can be added to a vehicle database record that notifies interested persons that the selected vehicle(s) is to be transferred out of the rental fleet and into the used vehicle market.
While the principal advantages and features of the invention have been discussed above, a greater understanding of the invention including a fuller description of its other advantages and features may be attained by referring to the drawings and the detailed description of the preferred embodiment which follow.
FIGS. 3(a)-(c) illustrate respectively, a preferred log-in screen, a preferred change password screen, and a preferred session timeout screen for the fleet management application;
FIGS. 5(a) and (b) illustrate, respectively, a preferred unauthorized access screen and a preferred technical difficulties screen;
FIGS. 7(a) and (b) illustrate preferred residual value table screens;
FIGS. 11(a)-(c) illustrate preferred CGF analysis results screens;
FIGS. 14(a) and (b) illustrate preferred tools for mapping YMMSs into YMMS groups; and
Fleet management application 102 is preferably a software application programmed to allow users to obtain (1) meaningful data about the historical sales prices for rental vehicles in the fleet that previously were sold as used vehicles, thereby enabling more accurate estimation by the user of residual values for rental vehicles in the fleet, and (2) meaningful data about the cost going forward (CGF) for rental vehicles in the fleet, thereby allowing users to make informed decisions about which rental vehicles to remove from the fleet and place into the vehicle sales market. This software can be loaded onto computer readable media such as the hard drive(s) of one or more servers accessible to user computers connected thereto via a network. This network can be any type of network over which data is communicated, including but not limited to the Internet, an intranet, a satellite network, a wireless network, a cable network, etc. For example, the software that is programmed to carry out the fleet management application can be loaded onto one or more servers accessible over a company's intranet for execution on demand by company computers that are connected to that intranet. Further, the one or more servers upon which the application 102 is loaded can be connected to the Internet to provide a wider range of users with access to its features. Further still, it is conceivable that the fleet management software and/or fleet database could be stored on other computer readable media such as a CD-ROM, a PC or laptop hard drive, PDA, any other type of mobile/portable computing technology, or the like.
After successfully logging in via screen 200, the user is presented with the fleet management home page 208 depicted in
The current location display section 400 allows users to view and/or specify constraint information (preferably geographical constraint information) on the scope of vehicle data to be processed by application 102. Field 402 identifies the high level area from which the vehicle data will be drawn. Field 404 identifies a lower level area from which the vehicle data is drawn, and field 406 identifies a yet lower level area from which the vehicle data will be drawn. In the preferred embodiment, the high level area is a country or continent (e.g., US, Canada, North America, Great Britain, Germany, Europe, etc.), the next lower level area is a country/continent subregion (e.g., southern California, northeast Ohio, mid-Pennsylvania, etc.), and the lowest level area is a subregion within the subregion (e.g., the Los Angeles area within the U.S./southern California region). Numerical codes, alphabetic codes, or alphanumerical codes may be used to represent these different levels. The preferred nomenclature for this breakdown is country/group/region. However, it should be understood that different terminology, different geographical breakdowns, and different numbers of hierarchical levels can be applied to constrain the vehicle data as a matter of design choice by practitioners of the present invention. For example, an intermediate level could be added between the highest level area and the next level area that corresponds to a larger subregion within the specified country/continent (e.g., midwest, west coast, etc.). Further still, more or fewer levels could be put in place, even down to the rental branch location level. Moreover, the criteria for constraining the data need not be broken down by geographical area at all. For example, the vehicle data can be constrained by the business entities that own or operate the vehicles, whether the vehicles are leases or rentals, by vehicle manufacturer, by whether the vehicle is a domestic or import, etc.
Also, in the preferred embodiment, different users will preferably have different levels of access to different country/group/regions depending upon their authorizations within the company. Further, each authorized user will preferably be associated with a default value for country/group/region depending upon his/her level of authorization. Preferably, a fleet manager for the midwest region will only have “delete” access to midwest level (and lower) vehicle data, and his/her default country/group/region setting would be US/Midwest (with no default value being provided by the “region” level). Similarly, a fleet manager for the St. Louis area will preferably only have access to St. Louis area vehicle data, and his/her default country/group/region setting would be US/St. Louis. The default country/group/region setting for a fleet manager for the Miami area would be US/south Florida/Miami. A corporate level fleet manager, however, may be given access to all country/group/regions of the fleet. However, it is worth noting that some practitioners of the present invention may choose to place no authorization restrictions on users.
In a preferred embodiment, the country/group/region technique will be implemented as follows. For country field 402, the value therein will be the user's default value for country. Preferably, only corporate users are allowed to change the view to a different country. As such, for non-corporate users, the country field 402 is display only. For group field 404, the group values are displayed based on the country value in field 402. For all authorized users other than corporate users, the group value will default to the user's associated group value. In such cases, the group field 404 will be display only. Corporate users are preferably allowed to change the view to different group values. For region field 406, the region value is displayed based on the regionalized group value in field 404. Preferably, only corporate users or users authorized to access a group broken down into regions have the ability to change region values. For all other users, region field 406 is preferably display only. User control over any changes to the country/group/region values are implemented via user selection of change button 408.
Fleet summary display section 410 serves as a snapshot for the user of the current fleet status for the country/group/region identified in section 400. This display serves as a valuable tool for providing users with a near real-time view of the current mix of car classes within a fleet. The data displayed in the fleet summary section 410 is derived from the stored vehicle data in database 100 meeting the applicable country/group/region constraints. Beyond the country/group/region constraint, preferable rules for determining which vehicles in the database 100 should be displayed are as follows: (1) the vehicle's purpose within the fleet is a “daily rental”, (2) the unit's out of service date should be null, (3) trucks should be included, (4) vehicles that were purchased used should be included (although these vehicles should be excluded from any average mileage calculation), (5) vehicles whose original unit cost equals zero should be excluded, (6) vehicles whose monthly depreciation amount percentage equals zero should be excluded, (7) vehicles that are not yet officially activated within the fleet should be excluded, and (8) the vehicles must have been completely activated within the fleet.
The fleet summary is preferably broken down into three data category columns. A vehicle class column 412 identifies a vehicle class type (e.g., economy, compact, intermediate, full size, etc.). Each row 418a, 418b, . . . 418i corresponds to a different vehicle class. It should be noted that different companies may well use different types of vehicle classes and different criteria for assigning vehicles to vehicle classes. Current fleet column 414 identifies the number of vehicles with each vehicle class for the identified country/group/region. Row 420 includes total numbers for the current fleet column 414 and the current fleet mix column 416. The entries in column 416 identify the percentages that vehicles of the vehicle class sharing the row make up within the overall fleet for the identified country/group/region. The current fleet mix percentages are preferably calculated as: Current Fleet Mix (for Row k) equals 100 multiplied by the Current Fleet Value (for Row k) divided by the Current Fleet Total.
While it is preferred that the fleet summary display section 410 display fleet summary data broken down by vehicle class, it should be noted that this display section 410, if desired by a practitioner of the present invention, could also be used to display current fleet count and current fleet mix data that is further broken down to the YMMS level.
The fleet summary preferably also includes an “as of” date identifier 434 that identifies the date for which the fleet summary data is current (e.g., the time stamped date and time that the fleet database 100 was last updated, which at minimum is preferably a day-to-day update).
Recent activity display section 422 summarizes the most recent activities of the user in the various sections of the fleet management application 102. Typically, section 422 will display a summary of recent reports and/or data tables created by the user as well as links 436 and 437 to such reports/data tables. Link 436 takes the user to screen 216 of the residuals path 212. Link 437 takes the user to screen 224 of the CGF path 220. Column 424 identifies the type of report/data table that the user had recently created. If the report/data table relates to a residual value table, the data displayed in column 424 will preferably identify the fact that the report/data table relates to residual values as well as identify the pertinent YMMS for the latest residual value data viewed by the user (preferably using a descriptive name for the YMMS). If the report/data table relates to a CGF table, the data displayed in column 424 will preferably identify the fact that the report/data table relates to CGF values as well as identify the pertinent vehicle class (e.g., fullsize) for the latest CGF data viewed by the user. Column 426 identifies the pertinent country/group/region for each report/data table, and column 428 identifies the date (and preferably time) upon which each report/data table was last viewed. Rows 430a and 430b identify the particular column values for each recent report/data table.
Quick links display section 460 preferably includes a plurality of links to frequently-used industry sources for vehicle data. Preferably, the links that are displayed to the user are country-specific.
Feature gateway display section 440 serves as a jumping off point for the user to access the residuals path 212 and the CGF path 220 identified in
In the event the user tries to navigate from the home page 208 to a page that he/she is not authorized to access, the “unauthorized access” screen 206 (see
To enter the residuals path 212 and reach the residuals parameter entry screen 214 of
Current month display section 604 notifies the user of the current month for residual value entry. Link 606 is provided to allow the user to proceed to a residual value table screen 216, depicted in
Among the various sections of the residual table screen 216 are a user options section 700, an information section 716, a related tasks button 744, a residual table 750, and a navigational bar 446. Navigational bar 446 functions as described earlier in connection with home page 208. Also, user selection of link 714 routes the user back to the residuals parameter entry screen 214. Further, time stamp section 746 identifies the date and time the displayed table 750 was last updated (and preferably who (not shown) updated the table).
The user options section 700 preferably includes three sections therewithin: a current location section 400 that is operative as previously described, a change selections section 760, and a YMMS selection section 710. Further, it is preferred that the user be provided with the ability to minimize, maximize, and otherwise selectively size the user options section 700 within the residual table screen 216. For users who have the authorization to change the country/group/region values, it is preferred that a “change” button (not shown) be made available in the current location section 400 to provide the user with the ability to modify country/group/region values in a manner commensurate with his/her level of authorization.
Field 702 within the change selections section 760 allows the user to modify the selected vehicle class for the screen. Field 702 is preferably joined with a drop down menu that contains a list of the vehicle classes with the current location's fleet. Radio buttons 704 and 706 provide the user with the ability to display within YMMS selection section 710 either “all” of the YMMSs within the selected vehicle class or only those YMMSs within the selected vehicle class for which a current residual value report is “missing” for the current month. Preferably, the current month is displayed alongside “missing” radio button 706. Based on any selections by the user within change selections section 760, user selection of the “update list” button 708 will be effective to reload the residual table screen 216 with the modified entries.
The YMMS selection section 710 provides the user with the ability to select the YMMS for the residual table 750. As noted above, the YMMSs listed in section 710 will be either all of the YMMSs within the selected vehicle class for the specified current location (country/group/region) or the YMMSs within the selected vehicle class for the specified location and for which a current month's residual value report is not yet completed, depending on the user input in radio buttons 704 and 706. The sort order for the YMMSs within section 710 is preferably make, year, model, series (alphabetically where applicable and chronologically where applicable), although they are preferably descriptively displayed by YMMS. However, it should be understood that other sort orders can be used. Furthermore, it is preferred that each YMMS listed in section 710 also include an adjacent identification of that YMMS's total count or population within the current location's fleet. At the bottom of section 710, a total vehicle count for the entire vehicle class of the current location's fleet is preferably displayed. The YMMS row 712 for the currently displayed residual table 750 is preferably highlighted in some manner to help notify the user of which YMMS is applicable to the current table 750. By clicking on a row 712 of section 710, the user can choose the YMMS for which the residual table 750 is applicable.
Information section 716 preferably displays to the user a summary of the parameters for which and from which the residual table 750 was created. This summary information includes an identification of the YMMS applicable to the residual table 750, an identification of the total count for that YMMS within the current location's fleet as of a predetermined date (preferably the date that the fleet database was last updated, an identification of the current location (country/group/region) for the residual table 750, and an identification of the data source, which specifies the pool of vehicles within the fleet that will be used for the historical analysis to populate entries in the residual table 750. Through the data source links, the user will have the ability to change the pool of vehicles for which historical analysis is performed to a larger or smaller pool. For example, if a St. Louis group fleet manager feels it would be more helpful to include a larger pool of historical sales in the analysis than just those in the St. Louis area, then that fleet manager will have the capability to expand the pool of historical sales to be analyzed (e.g., to encompass the entire midwest market rather than just the St. Louis group). The preferred data source choices are Group, Market, and Country. If the “Group” choice is selected, then the historical values are calculated from YMMS vehicles within the group of the data source's fleet. If the “Market” choice is selected, then the historical values are calculated from the YMMS vehicles with the market to which the group of the data source's fleet belongs. The choices of how to place groups within larger markets is a design choice, but it is preferred that groups be assigned to their natural geographical areas such as east, south, central, and west. If the “Country” choice is selected, then the historical values are calculated from YMMS vehicles within the country of the data source's fleet. It is worth noting that, preferably, the scope of levels accessible to the user via the data source tool not be limited by the user's authorization level within the company. Further still, practitioners of the present invention may choose different criteria for data source constraints similar in nature to the options discussed in connection with current location display 400.
Residual table 750 presents the user with a vast array of historical sales data for vehicles of a YMMS that is the same or similar to the user-selected YMMS within the data source's fleet. Residual table 750 further allows the user to enter estimations for future residual values for the user-selected YMMS, guided at least in part by the user's analysis of the historical trends displayed via the table 750.
Residual table 750 is preferably formatted in the following manner. The current year values for the selected YMMS vehicle appear as the last row 722 of information on the bottom of the table 750. Directly above the current year, will be historical data for the previous year's YMMS, in the same format as the rows and columns for the current year. Residual table 750 preferably displays the three previous years of data for a YMMS group together with the current year's data. However, it should be understood, that more or fewer than three previous years can be displayed and that the user can be given the ability to specify how many previous years are to be displayed. If there is no historical data available for a similar YMMS in a previous year, then a “-” or the like is preferably displayed in the pertinent row and column.
Along with each year's row, there will preferably be twelve columns corresponding to the months of the year. Preferably, the first two columns correspond to the two previous months, the third column corresponds to the current month, and the next nine columns correspond to the next nine months. The arrangement of columns is preferably updated by the software at midnight on the first of each month. However, other arrangements of months within columns can be used. For example, some practitioners of the present invention may prefer that the columns be displayed in strict January through December order while others may prefer that the current month be listed first with later months following.
While it is preferred that rows in the table correspond to data for different YMMSs and the columns correspond to different months, it should be noted that practitioners of the present invention may choose different row/column arrangements. For example, rather than having columns correspond to months, the columns could correspond to different time periods (e.g., quarterly). Also, the table can be arranged such that some rows correspond to country-level sales of a YMMS, some rows correspond to market-level sales of a YMMS, some rows correspond to group-level sales, and some rows correspond to region-level sales.
In row 742 for each month, the residual table 750 preferably displays an average mileage calculation for previous sales of the same or similar YMMSs in that month. Before explaining these average mileage calculations, it will be helpful to discuss the system's technique for pooling the appropriate historical data.
When attempting to estimate future residual values for a particular YMMS such as a 2004 MMS, it will be helpful to know how previous year MMSs have sold. In this case, a YMMS group of the same or similar YMMSs for a user-selected YMMS of a 2004 MMS would be the 2003, 2002, 2001 and so on versions of the MMS, as determined by a user. However, it may be the case that the process of grouping YMMSs into a YMMS group that corresponds to a user-selected YMMS is not so simple as finding matching MMSs for previous years. For example, in some cases, the name of the make, model, and/or series may have changed over time, despite a current YMMS still being the same “type” of vehicle as the older YMMSs. So that the fleet management application can accurately know which YMMSs to take into consideration when performing a historical analysis for a user-selected YMMS, the mapping tools of FIGS. 14(a) and (b) are preferably used.
A good case study for mapping is the Chevy Malibu. Going back to 2002, consider the following vehicle types: 2002 Chevy Malibu, 2003 Chevy Malibu, 2004 Chevy Classic, 2004 Chevy Malibu, 2005 Chevy Classic, and the 2005 Chevy Malibu. When mapping similar vehicle types together for the 2005 Chevy Classic, it is preferred that the 2002 Chevy Malibu, 2003 Chevy Malibu, and 2004 Chevy Classic be grouped therewith. When mapping similar vehicle types together for the 2005 Chevy Malibu, it is preferred that only the 2004 Chevy Malibu be grouped therewith. This mapping result arises from a change in design from Chevy wherein the 2004 Chevy Malibu was sufficiently different from previous years of the Malibu to render sales data for previous year Malibus relatively immaterial thereto. However, the Chevy Classic introduced in 2004 was sufficiently similar to the previous year Malibus so as to justify their user-defined grouping for historical sales analysis.
Once the appropriate YMMSs have been mapped into YMMS groups, a historical analysis of the average mileages by month of sale for a user-selected YMMS can be performed. This average mileage will be based on the odometer readings at the time of wholesale/retail sale for vehicles in the YMMS group corresponding to the user-selected YMMS. The formula used to calculate the average mileage is the sum of the odometer readings (at the time of sale) for all vehicles matching the YMMS group that were sold in the same month as the column in question divided by the total number of vehicles matching the YMMS group that were sold in the same month as the column in question, wherein the sales that are included in this analysis are the sales dating back to the earliest year for which reliable sales data is available (which is the year 1998 in the preferred embodiment). However, fewer years (or more years) of sales data could be used to calculate each month's average mileage.
Furthermore, to be included in the pool of past sales used in the calculation, it is preferred that a vehicle sale for a member of the YMMS group must meet these additional criteria: (1) the vehicle's sale date must not be blank, (2) the vehicle must have had a status of “daily rental” prior to the sale, (3) the vehicle was not purchased used, (4) the vehicle must not have been brought from leasing nor is a corporate or company car, and (5) the vehicle must have had more than 5,000 miles on the odometer at the time of sale.
In row 726 for each model year row 722, the monthly column entries will display a calculated historical sales price for each year of YMMS within the YMMS group, wherein the historical sales prices have been normalized to the corresponding average mileages in row 742. In the example of
Conceptually, with this technique the actual sales price values and actual mileage values for previously sold vehicles of a particular YMMS group can be thought of as a data group. The goal of the concept is to normalize each sales price value in the data group to a “representative” data group member (the representative member preferably being the average mileage value computed in accordance with
With reference to
Using this table as an example, and assuming that a vehicle's (say, a hypothetical YMMS of a 2004 xxxx yyyy zzzz) actual sales price is $8,700, that vehicle's actual odometer reading at the time of sale was 12,300 miles, and that the average mileage to which the sales price will be adjusted is 15,400 miles, then the calculation of an adjusted (or normalized) sales price will proceed as follows.
First, one would look to the cost per mile table to find an entry in the table for the vehicle's actual mileage, which in this example is 12,300. If a matching mileage entry is found in the table, then the “cost” parameter is easily set to be the cost value sharing the row with the matching mileage entry. However, if a matching entry is not found, then interpolation (preferably straight line interpolation) based on the next lower and next higher table entries can be used to find cost. In this example, interpolation will be needed. Thus, one preferably first calculates the cost per mile between 12,000 miles and 13,000 miles which comes out to $46 ($7,841-$7,795) for 1,000 miles, or 4.6 cents per mile. Using this cent per mile adjuster, the next step is to find what the appropriate entry in the table would be for a mileage of 12,300. Given that each additional mile added to the vehicle after 12,000 miles (and before 13,000 miles) is assumed to drop 4.6 cents from the vehicle's sales price, it can be determined that 300 additional miles on the vehicle would drop $13.80 (0.046 times 300) from the value of the vehicle at 12,000 miles. Thus, the appropriate cost entry in the table for a 2004 xxxx yyyy zzzz at 12,300 miles would be $7,827.20.
Next, the appropriate cost entry in the table is determined for a 2004 xxxx yyyy zzzz with average mileage (15,400) thereon. If a matching mileage entry is found in the table, then the “cost” parameter is easily set to be the cost value sharing the row with the matching mileage entry. However, if a matching mileage entry is not found, then the same interpolation process described above can be followed. In this example, interpolation will be needed. The cents per mile adjuster between 15,000 miles and 16,000 miles is readily calculated to be $46 (7,704 minus $7,658) for 1,000 miles, or 4.6 cents per mile. Then the table's cost entry for 15,400 miles can be readily determined. Given that each additional mile added to the vehicle after 15,000 miles (and before 16,000 miles) is assumed to drop 4.6 cents from the vehicle's sales price, it can be determined that 400 additional miles on the vehicle would drop $18.40 (0.046 times 400) from the value of the vehicle at 15,000 miles. Thus, the appropriate cost entry in the table for a 2004 xxxx yyyy zzzz at 15,400 would be $7,685.60.
Next, the table's cost difference for a 2004 xxxx yyyy zzzz with 12,300 miles (the actual mileage) and a 2004 xxxx yyyy zzzz at 15,400 miles (the average mileage) is determined. This cost difference is readily computed to be $141.60 ($7,827.20 minus $7,685.60).
Using this calculated cost difference, the actual sales price of $8,700 at 12,300 miles can be normalized to a value at 15,400 miles by reducing the actual sales price by the calculated cost difference. Accordingly, $8,700 at 12,300 miles would be normalized to $8,558.40 at 15,400 miles.
This $8,558.40 represents a normalization of the vehicle's actual sales price to the average mileage, thereby providing an indicator of what the sales price for the vehicle would have been had the vehicle had 15,400 miles on the odometer at the time of sale rather than 12,300 miles.
If the vehicle's actual odometer reading at the time of sale is less than the average mileage to which the sales price is to be adjusted, then it can be expected that the sales price adjustment will be a downward adjustment, as in the previous example. If the vehicle's actual odometer reading at the time of sale is greater than the average mileage to which the sales price is to be adjusted, then it can be expected that the sales price adjustment will be an upward adjustment, as in the following example. Assume that a vehicle's actual sales price is $8,000, that vehicle's actual odometer reading at the time of sale was 15,000 miles, and that the average mileage to which the sales price will be adjusted is 13,000 miles. In this case, the calculation of an adjusted sales price will proceed as follows.
First, one would look to the cost per mile table to find a cost entry in the table corresponding to the vehicle's actual mileage (15,000 miles), which in this example is $7,704 (no interpolation would be needed because an exact matching mileage entry is found in the table). Next, the table's cost entry for the average mileage of 13,000 miles is determined. In this example, the table's cost is $7,795 (once again, no interpolation is needed) for 13,000 miles. Once the table entries corresponding to the cost at the actual mileage and the average mileage are known, the difference between these two values can be calculated. In this example, the difference is $91. The adjusted sales price for the vehicle is then $8,091 which represents the actual sales price plus the calculated difference.
It should be noted that the cost per mile table shown above is exemplary only. Each practitioner of the invention may choose to populate the cost per mile table entries with values that correspond to their own business judgment. A preferred technique for creating the cost per mile table is described in Appendix A attached hereto. As described in the flowchart of
After all of the entries for rows 724 have been populated with the calculated average historical sales price normalized to that month's average mileage, then the entries for rows 726 and 728 can be automatically populated. Rows 726 represent the yearly sales price changes for YMMSs within the YMMS group sold that month relative to YMMSs within the YMMS group sold that month during the previous year. Essentially, the yearly sales price change for Month M during Year Y is the calculated historical sales price in row 724 for Month M and Year Y minus the calculated historical sales price in row 724 for Month M and Year Y−1. In the example of
The rows 730 within table 750 are automatically populated with total vehicle sales counts for each month, as determined by the sum of vehicles passing the filter of
For any data entries for which no data is available, a “-” is preferably displayed in the pertinent field. For example, because the year 2000 models are the earliest models shown in table 750, it is preferred that row 726 for model year 2000 be left blank because there is no displayed model year 1999 with which to compare the yearly sales price changes.
For the current model year, an additional row 732 will be provided in which the user can input forecasted residual values in fields 734 for the selected YMMS. As this row represents a future prediction, it is present only beginning with the current month onward (and is either not present or left blank for previous months). When determining future residual value(s), not only will the user be able to look to year-year historical sales prices normalized to an average mileage, but the user will also be able to look to month-to-month historical sales prices. The month-to-month view will allow users to get a sense for how sales price will decrease or increase from month to month as a YMMS ages from month to month. It is believed that the combination of these beneficial historical views with the user's own business knowledge will enable to user to more accurately estimate future residual value than was available with previous known forecasting systems. These residual value forecasts will help drive the CGF analysis described below.
Once the user has completed a desired number of residual value forecasts in table 750 for the selected YMMS, user selection of “update residuals” button 738 will be operative to save the table 750 in the database and automatically populate the year-to-year and month-to-month changes in rows 726 and 728 as appropriate corresponding to the user-entered residual value(s). However, it is also preferred that table 750 be automatically saved whenever the user navigates to a new page from page 216 (although upon such navigation it may be preferred that a pop-up window ask the user if the table 750 is to be saved). If the user wishes to create/retrieve table 750 for the next YMMS listed in section 710, the user can click on the “next selection” link 740. If the user wishes to create/retrieve table 750 for the previous YMMS listed in section 710, the user can click on the “previous selection” link 736. If a residual table 750 is retrieved for which the forecasted values are more than 30 days old, it is preferred that a warning message to the effect of “values over 30 days old: please update” be displayed on screen 216, preferably just above table 750, below section 710 and to the left of the related tasks button 744.
As shown in
Returning to
As previously described, current location section 400 displays the current country/group/region values for the user and allows the user to modify the current country/group/region values (depending on the user's level of authorization).
Vehicle selection section 1000 presents the user with a list of selectable vehicle classes in rows 1002a, 1002b, 1002c, . . . for use in the CGF analysis. The vehicle classes are preferably listed in alphabetical order. Further, the vehicle class corresponding to the vehicle class of the most recent CGF analysis by the user is preferably highlighted upon the user's arrival to page 222.
Average miles per month input section 1004 preferably provides the user with a field 1006 in which the user can enter a forecasted monthly mileage that the user expects for vehicles of the selected vehicle class in the near future. At the beginning of each calendar month, this value is preferably recalculated based on past history of the selected vehicle class, and this new average is then preferably displayed as a default value in field 1006. When a user enters a new value in field 1006, it is preferred that this new value be saved as the user's preference such that the new value will be appear by default for the remainder of the month when the re-accesses screen 222 for the selected vehicle class. Once that month ends however, it is preferred that a new default value be displayed. Preferably, the user will also be restricted from entering a value in field 1006 that is less than 1000 miles or greater than 9,000 miles. It is worth noting that section 1004 can also include a display of a suggested entry for field 1006, the suggested entry being derived data in the fleet database 100. This entry can either be displayed to the user in a text field or it can be displayed to the user as a selectable option (together with a second field for a user-entered value). It is preferred that this suggested entry, as well as a new default value in field 1006, be calculated by averaging the monthly mileages for all vehicles in the database that meet the following constraints: (1) the vehicle must be a daily rental, (2) the vehicle must have been a daily rental for longer than 35 days, (3) the vehicle must have more than 5,000 miles on its odometer, (4) the vehicle's average monthly mileage must not be greater than 9,000 miles, and (5) the vehicle must not have been purchased used.
Projection period input section 1008 preferably allows the user to specify the projection period for the CGF analysis. Field 1010 displays the current month for the projection period. Field 1010 is preferably display only. The user inputs the end month for the projection period in field 1012. Preferably, the projection's end month can be from one to six months from the current month. These end months that are available for selection can be listed in a drop down menu associated with field 1012. However, it is worth noting that more or fewer months can be used in the projection period. Further, it is worth noting that this projection period need not be specified in terms of months at all. Other time periods (for example, quarters) could be used.
Once the user has entered the pertinent parameter values on page 222, user selection of the “view results” button 1014 will be effective to launch a CGF analysis for the YMMSs of the selected vehicle class for the displayed country/group/region, using the average monthly mileage in field 1006 and the projection period specified by fields 1010 and 1012. The results of this CGF analysis will be presented to the user via the CGF analysis results screen 224.
Within the user options section 1100 is a current location section 400 that is operative as previously described. Also included in section 1100 is a change selections section 1102. Section 1102 provides a field 1104 that allows the user to change the vehicle class selected for the CGF results (preferably, the vehicle class options are presented to the user via a drop down menu associated with field 1104). By default, field 1102 preferably displays the currently selected vehicle class. Section 1102 also preferably provides a field 1106 that notifies the user of the starting month (i.e., the current month) in the projection period as well as a field 1108 that allows the user to enter a new ending month for the projection period. Field 1108 is preferably defaulted to the currently selected end month for the projection period. Further, section 1102 preferably includes a field 1110 in which the user can enter a new average miles per month value. Field 1110 preferably defaults to the current value for the average monthly mileage. “Update” button 1112 is preferably provided in section 1102 to allow the user to refresh screen 224 in accordance with any updated values in section 1102.
Information section 1114 informs the user with displays of the currently selected vehicle class, the currently selected location (country/group/region), the currently selected projection period and the current value for average miles per month.
The heart of the CGF results page 224 is found in the CGF results table 1120. The CGF results table 1120 provides current value and future value projections for the YMMSs of the selected vehicle class. Each row 1160a, 1160b, 1160c, . . . in column 1124 corresponds to a different YMMS within the selected vehicle class. Each YMMS listed in row 1160 preferably also serves a link to the most recent residual value table screen 216 for that YMMS.
For each listed YMMS in rows 1160, there is preferably a column 1126 for the current mileage as of the current month of the projection period. This value is the average mileage value in row 742 of residual table 750 for the current month and the YMMS in question.
For each listed YMMS in rows 1160, there is also preferably a column 1128 for the projected average mileage for that YMMS at the end of the projection period. This value is the current miles value in column 1126 for that YMMS plus the average miles per month selected for the CGF analysis multiplied by the number of months in the projection period.
For each listed YMMS in rows 1160, there is also preferably a column 1130 for the current residual value for that YMMS. This value is the residual value entered by the user in field 734 of residual table 750 for the current month.
For each listed YMMS in rows 1160, there is also preferably a column 1132 for the projected residual value for that YMMS at the end of the projection period. This value is calculated using the residual value entered for that YMMS in field 734 of the residual table 750 for the end month of the projection period. This residual value is then adjusted for the projected mileage that the YMMS is expected to have at the end of the projection period in accordance with a cost per mile table that relates vehicle values on a mileage basis.
An example will help illustrate how the projected values in column 1132 are calculated. Assume that the pertinent values in the residual table 750 for the YMMS in question at the end month in the projection period are as follows for a 2004 xxxx yyyy zzzz:
May: $9,500 for an average mileage of 12,000 miles
July: $8,400 for an average mileage of 14,000 miles
Further, assume a two month projection and an average miles per month value of 2,000 miles. Further assume that the current month is May. Using these numbers, the projected mileage will be 16,000 (the base mileage of 12,000 plus two months of 2,000 miles). The goal is to calculate the projected value for a 2004 xxxx yyyy zzzz at 16,000 miles from the residual values of $8,400 at 14,000 miles in July and $9,500 at 12,000 miles in May. In making this projection, the exemplary cost per mile table shown above will be used. This table is preferably created and used in the same manner described above in connection with the residual table and as set forth in Appendix A.
From this table, it can be seen that the cost adjustment between 14,000 miles and 16,000 miles is a downward adjustment of $92. Accordingly, to normalize the end month residual value for the YMMS to the projected mileage, the end month residual value needs to be decreased by $92. Therefore, in this example, the projected value for the 2004 xxxx yyyy zzzz in July assuming 2,000 miles per month will be $8,308 ($8,400 minus $92).
If exact matching entries are not found in the cost per mile table for the end month average mileage and/or the end month projected mileage, then interpolation can be used as described in connection with the residual table 750 to arrive at the appropriate table cost values.
For each listed YMMS in rows 1160, there is also preferably a column 1134 for the cost going forward (CGF) for that YMMS at the end of the projection period. This CGF value is calculated as the difference between the projected value for the YMMS in column 1132 and the current value for the YMMS in column 1130. These CGF values display to the user the expected changes in value for each YMMS from the start of the projection period to the end of the projection period. The YMMSs in table 1120 are preferably sorted by their CGF values in column 1134 such that the YMMSs with the largest negative CGF value are displayed at the top of the table. However, this need not be the case.
An additional preferred feature of the CGF results table 1120 is the mileage band section 1136. Section 1136 comprises a plurality of columns 1138 through 1152, each column corresponding to a different range of mileage values, preferably progressing from lower mileages to higher mileages. Populating each row in column 1138 through 1152 is preferably a count of the number of vehicles for that row's YMMS that fall within the pertinent mileage ranges. The entries in column 1170 for each YMMS correspond to the total count of vehicles in the fleet of interest for that YMMS (subject to the country/group/region and other constraints previously described). These classifications and counts of YMMS vehicles are readily achieved by filtering data in the fleet database. In the example of
Furthermore, it is preferred that each entry 1162 in the mileage band section 1136 serve as a link to an activation page for those vehicles in the YMMS mileage band. As will be described in connection with
For each listed YMMS in rows 1160, there is also preferably a column 1196 for identifying a count of YMMS vehicles within the pertinent total number of column 1170 that have been activated for deletion from the current location's fleet. The entries in column 1198 for each row 1160 thus identifies a count for the remaining unactivated YMMS vehicles within the pertinent column 1170 total count.
Furthermore, it is preferred that each YMMS row in table 1120 include a column 1122 that provides warning notes to the user. For example, in rare circumstances a CGF value may be found to be positive. It is preferred that such anomalous values be flagged for the user's attention so that the user can evaluate the accuracy of the underlying data (e.g., the residual value forecasts). To do so, a warning icon 1192 can be displayed in the appropriate row of column 1122. Additionally, descriptive language for the warning icons 1192 can be displayed on screen 224 above the table 1120, below section 1114 and to the left of related tasks button 1180. Additional examples of warnings for the user can be an “invalid forecast values in the residual table” warning and a “please, enter only numeric values” warning, as shown in
As shown in
As previously mentioned, if the user selects one of the links 1162 in CGF results table 1120, the activations screen 230 of
Information section 1300 provides the user with the information presented in the row 1160 in the CGF results table 1120 for the YMMS corresponding to the link 1162 that was selected by the user. However, the only mileage band count that will be shown in section 1300 is preferably the count for the link 1162 that was selected by the user. It is also preferred that the activated count from column 1196 for the pertinent row in CGF table 1120 be identified in column 1302.
The activations table 1310 preferably displays pertinent data about each listed fleet vehicle in the selected YMMS mileage band and further allows the user to flag specific vehicles for deletion from the fleet. Each row 1326a, 1326b, 1326c, . . . in the table 1310 corresponds to a different vehicle in the fleet meeting the YMMS and mileage band constraints. Column 1314 displays the unique identifier for each vehicle. Column 1316 identifies how many months each vehicle has been in service. Column 1318 identifies the latest odometer readings for each vehicle. Column 1320 identifies the group and branch location where the vehicle resides Column 1322 identifies the exterior color for each vehicle. Lastly, column 1324 identifies the book value for each vehicle (as determined by an accounting or financial department)
Based on the user's assessment of which vehicle(s) listed in table 1310 should be deleted from the fleet and sold as a used car, the user can check individual boxes in the “activate” column 1312. User selection of the “clear” button 1328 will be effective to clear all of the checked boxes in column 1312. Preferably, page 230 also includes a “check all” button (not shown) and an “uncheck all” button (not shown) that are effective, upon user-selection, to respectively check each box or uncheck each box in column 1312 automatically. User selection of the “activate” button 1330 will be effective to flag each vehicle having column 1312 checked for deletion. Once flagged, an appropriate message is preferably communicated to the person in charge of the flagged vehicle (e.g., the branch manager at the branch location where the vehicle is available for rent), thereby allowing the message recipient to promptly pull the vehicle out of the rental fleet and make arrangements for its transfer to the used car market. Alternatively, a database record for an “activated” vehicle can be created that flags that vehicle for deletion. An interested party can thereafter receive a message or report from this database record to become notified of the need to delete the vehicle from the rental fleet and move it to a used car market.
Related tasks button 1334 is preferably selectable by the user to present the user with options to either export the data of screen 230 to Microsoft Excel or to create a printer-friendly version of screen 230 for printing.
It is worth noting that the selection of any of the links 1162 from screen 224 in columns 1170, 1196, or 1198 also navigate the user to an activations page 230. For users who arrive at page 230 from a link in column 1170, the activations tables 1310 will list each fleet vehicle within the YMMS corresponding to the selected link. For users who arrive at page 230 from a link in column 1196, the activations table 1310 will list only the fleet vehicles within the YMMS corresponding to the selected link that are scheduled for deletion. Lastly, for users who arrive at page 230 from a link in column 1198, the activations table 1310 will list only the unactivated fleet vehicles within the YMMS corresponding to the selected link.
While the present invention has been described above in relation to its preferred embodiment, various modifications may be made thereto that still fall within the invention's scope, as would be recognized by those of ordinary skill in the art upon review of the teachings herein. For example, while the preferred embodiment is concerned primarily with rental vehicles, the present invention can also be practiced in connection with calculating normalized historical sales prices and CGFs for leased vehicles. Also, while YMMS serves as convenient criteria for distinguishing between different vehicle types in North America, when dealing with fleets located in countries outside North America, other criteria could be useful. For example, in the United Kingdom, effective criteria would include registration year, registration letter, make, model, spec year, trim, engine size, horsepower, series, gearbox, fuel type, etc. In Ireland, effective criteria would include registration year, spec year, make, model, trim, engine size, horsepower, series, gearbox, fuel type, etc. In Germany, effective criteria would include registration year, spec year, make, model, series, engine size, kilowatts, trim, gearbox, fuel type, etc. As such, the full scope of the present invention is to be defined solely by the appended claims and their legal equivalents.
This appendix describes a preferred technique for creating a cost per mile table.