The financial year-end is approaching and software sales people are tightening their vises. They’re looking to get one more giant grab at your corporate coffers and help themselves to some coin before the year concludes. They’re clearly acting in their self-interest but may not be acting in yours.
You know you’re in for a bruising in these encounters when:
- Your ERP vendor, who has been sitting on their audit of your application usage, is just now (and finally) announcing the dreaded results of that audit. However, they’ll time this ‘news’ so that you won’t have sufficient time to review or negotiate the added costs/findings. (Oh, and don’t expect them to give an inch of credit for all of those thousands of unused full user licenses you’ve been paying for all these last 3+ years!)
- The vendor is willing to tie some of these adverse audit results to add-on product or platform upgrade sales opportunities. This, of course, can only happen if you bundle it all together in time for them to make their year-end bonuses and post solid Q4 and YE results for the firm.
- The ‘deal’ they want you to bless is actually:
- Several different agreements for public cloud, private cloud, hosted and hosted-that-could-someday-be converted-to-a-private-cloud/public cloud solution
- A deal that requires you to cut other deals with implementers, application hosting service providers, hyperscalers, application maintenance providers, etc.
- A reimplementation of your old product with less functionality but at an all-new price
- A reimplementation that requires a lot of third-party implementation costs with little real improvement in business efficiency or productivity
- A solution where many of the applications must be maintained by third parties – not the software vendor
Unfortunately, their shenanigans will come at the expense of the bank accounts of many firms and the vendors don’t care.
Paying 2-5X for essentially the same product
Many software users simply aren’t examining the economics of what’s being presented to them.
In the old days, you negotiated a perpetual license to use the software. Unlike a subscription, this was your software to use, forever! Within 30 days or so of signing the license deal, you began paying an annual maintenance fee of 8-25% of the negotiated software license price. Cost escalators often triggered the actual maintenance fee to increase 10% or more annually with maintenance costs effectively doubling after seven years.
In recent years, when maintenance fees got to be 22-25% of the license costs, then maintenance costs effectively doubled in as little as three years thanks to the power of compounding. The net effect of this is that many customers have paid for their perpetual license many, many times over due to the maintenance monies dwarfing the license fee. This begs the question, if you’ve already licensed the product and you’ve paid enough maintenance fees to license it many more times, then why should the cloud version of the product cost you anything at all?
Software buyers were supposed to get something for all that maintenance money. They were to get periodic upgrades of the products, regulatory and compliance updates, phone support, etc. So, if you’ve been paying maintenance for 20 years, why are you being asked to pay again for the cloud-y version of essentially the same product? What did all this maintenance money pay for?
The permanent tax
In the SaaS world, the upfront license payment goes away to be replaced by a monthly or annual subscription fee. And, when multi-tenancy is added to SaaS, the application software vendor would update the one-copy of the code for all customers as part of the service. That’s a key point: the vendor, not the customer or an application maintenance provider, now provides the maintenance as part of the subscription fee.
Vendors who sell a non-multi-tenant ‘cloud’ or mixed solution are imposing a long-term, if not permanent, tax on their customers. These customers must either choose to maintain these non-multi-tenant (NMT) apps themselves or pay an application maintenance firm to do this for them. This outsourced service is not cheap and it carries risks as the third party has to understand all of the tailoring and customization the customer has made to the product, especially if the product is allowed to get several releases behind.
In three recent negotiation calls last week, not one customer seemed to care about this material cost element. The attitude was that the technology or operations people wanted to do this deal and if this a condition of using the software, then so be it. When the wrong people are making upgrade decisions (e.g., techies who don’t look at the $) or when people aren’t being good stewards of their firm, then they’ll make bad decisions that can have huge, long-term, negative financial implications for their firm.
Usually, these customers are going with a familiar vendor/product and not looking around for other, possibly better or lower cost alternative solutions. After 20 years with one solution, it’s imprudent not to do a selection project and exercise some measure of diligence in this decision. And, if you intend to keep this new solution for another 20 years, are you prepared to pay (possibly needlessly so) for 20 years of someone else maintaining this?
Also, if you’re bound and determined to go with one of these cloud-y solutions, then make the vendor heavily discount the subscription price as they aren’t providing the one key ingredient of a great cloud solution: vendor provided maintenance via multi-tenancy.
The inferiority of cloud-y solutions
Some ERP vendors did a terrible job of creating new cloud-like or cloud-y applications. These companies tried one or more of the following techniques to modernize their old-school products:
- Added some peripheral cloud application (e.g., a data warehouse, a collaboration tool, an HR application, etc.) to essentially an updated on-premises product
- Acquired some pure cloud products and loosely integrated them to their older product line
- Reworked their old product architecture stack to replace the database or add new components like a micro-services capability
However, what they didn’t do was more telling. The old functionality was essentially left intact as the vendor wanted to provide a migration path for prior customers to move to the new solution. Unfortunately, the old data models needed work. One vendor has six different check/payment processing modules within their suite because of acquisitions and an unwillingness to touch the code within their older, legacy applications. These solutions aren’t rewritten or reimagined applications, they are port-overs.
Software buyers today need to ask a couple of tough questions. First, if a software vendor is automatically providing maintenance with their some of their SaaS applications (e.g., those for HR and CRM), then why aren’t they doing so for their more operational systems (e.g., MRP, warehouse distribution) or vertical functionality applications? Chances are the vendor acquired the back-office applications and those came with multi-tenancy while their own applications never got the capability.
A software vendor that still can’t deliver multi-tenancy will have long-term issues that will adversely affect its customers (Note: vendors like Salesforce, Plex and NetSuite have had this capability from around 1999). First, the vendor is building another massive customer install base with their SaaS customers on slightly or materially different code and databases. Once these customers start to diverge, it will be very hard for the vendor to get the multi-tenancy genie back in the bottle.
Additionally, with all these customers running the code on their own private clouds or in numerous hosted computing environments (e.g., hyperscaler or outsourcer), the vendor may struggle to capture data for benchmarks or data to make its algorithm powered machine learning tools (e.g., analytics, chatbots, etc.) smarter and better.
When vendors can’t aggregate (dissimilar and/or isolated) data, viable benchmarks or great algorithmic data stores are out of reach. Even if vendors find a way to get access to this distributed and diverse data, they may not be in a position to fully understand the data they get as the customer may have modified the software, added custom fields or made other changes that affect the nature of the data within the system.
Why are some vendors unable to deliver multi-tenancy?
There are several possible reasons and customers would do well to demand answers from their potential software vendor. First, adding multi-tenancy costs money when you have to retrofit it into an on-premises solution. Second, the vendor may have jammed together a number of acquired products with each solution possessing its own technology stack, database, data model, etc. Interestingly, some of the acquired solutions may be multi-tenant while older core applications may or may not be. As it turns out, not all multi-tenant solutions are good ones. Kludged solutions make for poor multi-tenancy candidates.
All of that systems diversity in these kludged suites means that the vendor will need a record amount of scheduled downtime to provide application maintenance. Lots of scheduled downtime is needed as each product line within the suite has its own upgrade cycle, its own technology stack, etc. (It’s not the Power of One world that Workday possesses). Customers want scheduled downtime to be a few minutes per quarter not the hours and hours of downtime that a stitched together, loosely integrated suite might contain. When that environment exists, customers will want to control their own upgrade timing and will not want a poor multi-tenant solution.
When vendors have on-premises/hosted and multi-tenant versions
A funny thing may happen when you choose a vendor whose products can operate in either an on-premises/hosted or multi-tenant deployment model. If a vendor has hundreds or thousands of customers using its multi-tenant solution, it may choose to put its best technical resources on supporting that version of the product. It would be logical to do so as the vendor can’t afford the brand damage it would incur if thousands of customers were experiencing problems with the software.
If one on-premises/hosted customer is having an issue, that presents a far lesser threat to the vendor’s reputation. So, being an on-premises/hosted customer may not be in your firm’s best interest in this scenario as you’ll likely get the “B” team when it comes to support issues.
Other bad economics
When software customers cannot get a multi-tenant solution, they may incur a different economic cost: technical debt. This is a familiar issue for anyone that’s had on-premises software and chooses not to keep the software current for a period of time.
The accumulation of technical debt is an artifact of a bygone technology era. Any software vendor that tries to defend this or tries to spin it as a customer desirable option is doing your firm a disservice.
If you’re getting rushed into some bad year-end software purchase decision, make sure you know how your firm and its bank account will be impacted. Specifically, be sure to account for:
- The cost of third-party hosting for the life of the subscription
- The cost of third-party application software maintenance for the life of the subscription
- The cost of third-party service level management for technical support and incident management
- Increased costs to debug problems (especially if your firm customizes the solution)
- Costs to test integrations between the suite, its component solutions and other applications your firm uses
- The cost to acquire the subscription version of the software when your decades of maintenance payments for the on-premises solution should have provided this for free
- The cost to change your processes, interfaces, etc. to accommodate functional shortcomings in the new SaaS versions of the product
And another take...
Several years ago, a colleague of mine was quizzing the CEO of a major ERP vendor. In particular, he was probing why the vendor didn’t do a better job of policing its implementation partners and their very high costs. The CEO wasn’t having it and pushed back. He argued that their customers were large firms with procurement, legal and other experts in-house or at their disposal. These customers, he continued, knew how to negotiate and didn’t need his firm to make the market a better, easier place to navigate. (Note: none of the other analysts present bought that CEO’s argument.)
We could have the same discussion today except that instead of debating the implementation ecosystem it would focus on the move to SaaS. I can almost hear the vendors saying that they have big companies as customers and these customers should have the expertise to do these deals on their own.
My experience is that too many of these large firms are either naïve or overly trusting when it comes to dealing with ERP vendors. An attitude persists in these ERP firms that implies, 'We will take advantage of our customers at every turn and it’s up to the customer to get all the help they can to avoid getting reamed.' Last I checked this isn’t “Customer Experience”.
Get help folks! Lots of help!