Earlier this year, some of my colleagues here at ARC wrote a Strategic Report titled “Capital Expenditure Survey 2009” (available to ARC clients only). The report got me thinking about the differences between how hardware and software are expensed, and how those differences affect a logistics executive’s annual budget.
I talked to executives at some of our logistics software vendor clients, including i2 Technologies, RedPrairie, Manhattan Associates, and Tecsys, to see how their customers approached this issue. According to these vendors, companies typically depreciate software within three to five years, a much shorter timeframe than expensive capital equipment. However, the ROI model customers use to justify software purchases can be quite different. Manhattan Associates, for example, reports that in helping customers put together a ROI model it often shows costs versus savings, and the time value of money, over a five to seven year timeline.
How do these budgeting issues affect logistics executives? In my conversations with them, almost all report that the annual budgeting cycle involves cost targets, and these logistics costs roll up to the Income Statement.
For logistics executives with private fleets, the Balance Sheet also comes into play. For these executives, one of their annual budget exercises is to look at their trucks and decide which ones to sell based on their book value, whether a truck is experiencing excessive downtime or increased maintenance or repair costs, and the opportunity costs involved (i.e., the costs of not investing in new equipment). New trucks might have better operating performance, in terms of fuel efficiency, safety, or emissions, so the differences in performance and quality between old and new equipment can be missed opportunities for performance improvements.
So, one key difference between software and hardware is that hardware has a book value, while software does not. The book value for hardware represents the resale value, which is reduced by annual wear-and-tear. Enterprise software contracts forbid customers from reselling their software and thus the software has no book value. Basically, there is an exit scenario for hardware that does not exist for software, and the Balance Sheet exercise described for private fleets would never take place for software.
The issue of wear-and-tear and opportunity costs takes a different form for software. Let’s take the wear and tear issue first. A company that buys a warehouse management or transportation management system would almost always purchase a maintenance contract, at least in the early years. The maintenance contract includes helpdesk support, which helps to keep the software up and running, and helps prevent downtime issues that can occur with aging equipment. If a company does not engage in periodic upgrades, the software might pass a point in time where helpdesk support is no longer provided.
The upgrades included as part of the maintenance contracts also include new functionality that allows for new performance improvements. Software maintenance and implementation services hit the Income Statement as an operating expense. While some companies I have talked to have decided to get an upgrade after every few releases (or in some cases, after every release), some companies perform an ROI analysis to determine whether the new functionality and performance improvements are worth the new costs that will impact their budget.
Based on the software’s architecture, some solutions are much easier to upgrade than others. If the software is relatively easy to upgrade, staying current is an easy decision. With other solutions, where upgrades require more costly implementation services, the upgrade decision is more difficult. This is because if you wait too long and there are many releases between the version you bought and the current release, upgrading becomes far more expensive, often rivaling a new implementation in terms of cost and time. In short, while an individual upgrade might not be cost justified when considered in isolation, there can be an opportunity cost associated with not doing periodic upgrades. From a budgeting perspective, the software’s architecture can matter greatly.
This is where the software-as-a-service (SaaS) model gets interesting. There are no capital expenses associated with SaaS, so software purchased under a SaaS contract doesn’t affect the Balance Sheet. Instead, all the costs and benefits hit the Income Statement. If the SaaS solution is single instance, multi-tenant, then there is minimal costs (often none) associated with upgrades. From a budgeting perspective, this strikes me as much cleaner. (For more on SaaS see “A Beginner’s Guide to SaaS and “More Questions about SaaS”).
