Rental computerization began in the 1970s. Back then, $100,000 to a $1 million or more got you a rental management software package and the refrigerator-sized computer required to run it. The system wrote contracts; computed rental fees based on time out; booked reservations; usually warned you if you were overbooked; automatically stored customer and item income; tallied revenue for sales tax and general ledger purposes; and most importantly, booked receivables and printed statements. Some integrated with general ledger, accounts payable and purchase order software. For larger operators they easily earned their keep. Today, for about a tenth of the price, running on a box about a tenth of the size, you have rental management systems with 10 times the features and 10 times the speed of the first systems.
The legacy systems were mainly transaction processors. Because of memory, disk space and programming limitations, they stored very little history. The enterprise systems of today store extensive transaction, customer and item history. Transaction history includes which employee created the initial quote, reservation or opening transaction, any modifications and all transactions that change line item status or involve payments or refunds.
These current generation enterprise systems use database engines to store all transactions. A click on the transaction history button in an item record displays transactions sorted by most recent activity. A click on the dollar amount column heading displays all transactions for the item sorted by most to least earned. A click on the customer column heading re-sorts all the transactions by customer. Similar things can be done with transaction records for a particular customer.
Storing transaction history is nice, but most rental store owners are interested in which items are generating the money. Legacy systems tended to store item income for month-to-date, year-to-date, prior year or two, and lifetime. At the end of the month an item income report would print out the income for the various periods. Suppose you have five walk-behind trenchers and you were interested in the monthly income trend for the units over a period of seven years. Because the data you need is only in report form, you'd have to look at 84 (7 years × 12 months) different printouts spread out over a big table. And, summing up the income of each serialized item would be daunting. It is reminiscent of the scene in “A Beautiful Mind” where the famous mathematician, John Nash, pastes newspapers on his garage wall trying to spot trends in the data.
Enterprise rental management systems solve the long-term income analysis by automatically storing a lot more data. Typically income is stored monthly for each item for at least 10 years. By arranging the income data in yearly columns by month (see Figure 1) most anyone can spot trends without resorting to printouts. The example shown is an item with decreasing income. This item's income is highly seasonal with revenue peaking in the spring.
Figure 2 is data from an item with increasing revenue over time. Now, these examples are nice and quite useful if you have one each of the items, but real rental stores have two, three, four or maybe 50 units of a given item. And they may have been purchased in different years and probably not all of them were even manufactured by the same company. A good example is 19-foot scissor lifts. Suppose you own 12 of these units. If so, you'll be interested in enterprise rental management systems that support header or master item records. The master record is a record that dynamically sums data from the individual serialized records related to it. They serve multiple purposes. One, instead of your counter employee being stuck with reserving a specific serialized lift, they reserve the master record. Then, several weeks later when the reservation is being converted to an “open” contract, the system displays all the individual serialized lifts with a red 0 and a green 1 to indicate which are out and which are available. The counter employee then picks which unit will be sent out to satisfy the reservation. Or, if your yardman determines which to send, this assignment can be delayed. In either event, when the actual serialized unit is put on the “open” contract, the master record will disappear.
The master record also sums all sorts of interesting data stored in the individual records. Figure 3 shows monthly income summed for all 12 lifts by year. In this example, other than a spike in 2001, the income trend is good. So, should you buy more units? Maybe. But, the income trend could be good even if you've never had all 12 units out on rent. The answer lies in knowing the frequency of how many units are out simultaneously. It gets complex, but the “quantity compare” data (Figure 4) shows that only once in the last four years were all 12 units out simultaneously. Eleven were never out simultaneously and on only two occasions were 10 units out. So, unless more demand can be created fast, 12 units are at least two lifts too many.
One final factor that will influence your goal of determining the optimum number of lifts to inventory is to review customers renting the lifts. Check the transaction history in the master record and sort them by customer. Scroll through the list. If one or two customers make a large percentage of the transactions, the whole analysis goes out the window unless you are confident that these customers will continue to rent from you. In any case, current generation enterprise systems can help you make well-educated purchasing decisions.
Bob Shaffer is president for Grand Prairie, Texas-based Point-of-Rental Systems. He may be reached at (800) 944-7368. www.point-of-rental.com.
