Software Maintenance for the Small Stuff
Most have concentrated on their ERP and other large, strategic vendors – but what about all of those little invoices that come every year – development tools, management utilities, network monitors, etc. After a while, it really adds up – but too often, we look at the relatively small amounts and just approve the dollars without a thought. It may be time to gather up these little guys, and take a good, long look.
- Why pay for something that we rarely use? Typically, I have purchased perpetual rights to use a product, but I pay annually to keep on support. Why not let the support / maintenance lapse, but continue using the product (on the rare occasion I need to)?
- Even if I use the software a lot – why pay maintenance if I rarely call support? Does the vendor offer support on a time-and-materials basis? Don’t dismiss this option out of hand – I find it difficult to believe that a vendor will turn down an opportunity to start hourly billings in the event that something significant goes wrong.
- Do I really need to pay support if I have scheduled a project in the near future to get it decommissioned? Just looking to realize the savings a bit earlier …
Alternatives and Duplicates
Are there alternatives available that would cost less on an annual basis?
- Do I have any point-solutions that can be replaced by unused, duplicate functionality in my ERP system? Something to consider, especially if the solution was implemented a few years ago. Perhaps the R&D group from your ERP vendor caught up to their competition?
- Is third-party support available? Rimini Street is the classic ERP example – possibly some consulting firms will offer support for the more mature, niche-stuff in your portfolio?
- Of course, there is always open-source; no acquisition cost, and [typically] no annual maintenance.
- Are there applications in your portfolio with similar / duplicate functionality? This is common for even mid-sized shops, especially as time passes and those pesky vendor developers keep improving and extending their core products.
Compare your Risk Requirements with Reality
As much as we grouse about vendors, IT departments often mimic their behaviors, especially when justifying software maintenance and infrastructure redundancy based on FUD (Fear, Uncertainty, and Doubt). How often does this stuff really fail? How bad is the software, how loaded with bugs, that we simply must have access to (and faithfully apply) every patch?
I’m not looking for a storm of protest here – I have plenty of “war stories”, just like you, of timely support calls that provided just the right patch, and untimely hardware failures that went unnoticed because of well-engineered failover. However, it’s time to think aggressively, and re-examine / revalidate all of your assumptions.
- How about reducing our level of telecommunications failover – can we get cheaper / slower backup circuits?
- Consider sharing backup servers between multiple applications – where the first failover application takes over, eliminating the second apps safety net.
- How often do my techs end up solving the problem for the vendor – how much value am I really getting, especially for the really mature stuff?
“Risk” is always powerful word, especially when dealing with a conservative management group. However, for this exercise we can’t just accept the powerful but un-valued justification of “risk mitigation” – we must quantify risk on an historical basis. For example – if we talk about dropping support for a software product, we can and should quantify how often we had to call up the vendor for support / help, or how many bugs we’ve fixed by applying a vendor patch.
Here’s the most important idea; we should be able to draw a clear line between cost and quality (where, in this discussion, “quality” = “risk mitigation”). If we want this level of quality, we have to pay this much money. If we want to save money, can we accept a lower level of quality (or, a higher level of risk)?
I always go into budget reviews with the idea that the business is asking for a thoughtful discussion of tradeoffs, and not dictating targets (no matter what the memo specifically says!) More often than not, the Finance group or the General Manager is asking questions like “how can we save $X ?”, or “what would it take to reduce by Y% ?”. The cost vs. quality/risk tradeoff is something that can and should be a joint decision between IT and the business.
