I’ll admit it. The moment I see that “Terms and Conditions” box come up on my screen, I’m hunting down the “Agree” checkbox as fast I can, just so I can get on with it and access the software already.
Compared to consumer software, social media, or app store sign-offs, ERP software agreements are a whole different ball game, of course. The stakes are simply significantly higher.
But one thing remains the same: Page after page of offputting contractual language can seem equally impenetrable in both instances.
The ramifications of incompletely reviewing ERP software licensing agreements are intimidating. All sorts of contractual gotchas are possible:
If you break a contract down to certain key components, though, and know what to look for, you can make sure that the license agreement you are entering into is something you can live with.
Determining the number of users your software will allow seems pretty straightforward, right? It’s just a simple number, no?
What is meant by the term “user” can actually vary in software contracts. The most common variants are “concurrent user” and “named user” licensing models.
A named user approach entails that one user license is purchased for each individual who will access the software. A concurrent user model on the other hand allows for an unlimited number of named users and accounts, but limits the number of individuals that can be actively accessing the software at a given time.
All other factors being equal, concurrent user licensing is a bit more customer friendly. For example, a company with four heavy users and two or three more occasional users who just need to take a look at reports periodically could likely suffice with five licenses rather than seven.
There are two standard approaches to determining the amount of time software can be used: perpetual and term-based licensing. Most sellers of traditional on-premise ERP solutions license their software on a perpetual basis. Simply put, once you purchase the software, you can use it as long as you like. (Support and services are another issue–but more on that shortly.)
Term-based licensing on the other hand is the standard model for software-as-a-service (SaaS) deployments. Generally, in a term based licensing agreement, use of the software will be contracted in monthly or annual intervals.
Hybrids of term and perpetual use arrangements are also showing up more and more. For instance, in some arrangements certain functionality may be provided perpetually, while other functionality might require term based renewals. A very common example of this can be seen in payroll modules that are part of a larger ERP system. Generally, you will need to renew the payroll software each year to get tax table updates (which are necessary for running payroll), while the other modules will function in precisely the same fashion as they always did.
Modular ERP systems provide the benefit of being able to license just the functionality that you require.
Given the a la carte nature of the menu when it comes to ERP systems, though, you do need to make sure that that your software licensing agreement covers the particular features and functions you’re expecting to receive.
In fact, it’s good practice to look beyond just your immediate needs to understand how modules which you may require later are licensed. For example, perhaps you’re currently using a 3rd party payroll service, but plan to license the payroll functionality in your new ERP solution upon completion of your service contract. Understanding if that payroll functionality is bundled into a broader suite of HR functions (which you may or may not want–or want to pay for) is worth considering.
The specifics of software editions are another area to keep an eye on. Whether the software developer makes distinctions between Gold/Silver/Bronze, Professional/Enterprise, or what have you, it can be a lot to keep straight during your evaluation. Reviewing the contractual language documenting the editions can reveal import limitations of particular versions and differences you should be aware of–which may or may not have been stressed during the sales process.
Implementing ERP software is complex. In most situations, the software seller will need to provide at least some of the implementation services. (For a breakdown of ERP implementation tasks, check out our article: “The CFO’s Guide to ERP Implementation.”)
When using a software provider for implementation services, the contract will need to not only precisely define the scope of work, but it should document:
Your need for support is unlikely to end after the implementation. Because of the complexity of ERP software, users will inevitably have questions when they run into jams and bugs will happen from time-to-time.
The software licensing agreement needs to adequately ensure you’ll be receiving the level of support you expect.
Everybody wants “good support,” but what does that really mean? To make sure you receive support that lives up to your definition, you’ll want to ensure the licensing agreement specifies what you’ll be provided with in terms of:
Software versions updates. They’re kind of like vitamins of the software world. You know they’re good for you, but you don’t always remember them.
It’s generally a best practice to stay current with software updates–not only to access new features, but in order to get bug fixes and security patches. Especially when you’re dealing with software that handles data as sensitive as what is held in an ERP solution, maintaining the strongest possible security profile against known threats is critical.
In most situations, ERP software updates will be bundled with support services for a negotiated annual rate. Some providers will distinguish between major and minor updates. For example, while going from version 1.5 to 1.6 may be covered in your basic “update assurance” package, sometimes you will find there are additional costs to go to version 2.0.
Here’s a little secret: Most sellers of proprietary software really don’t want to share their source code with you.
Some software providers will make their source code available to you for an additional cost, though. Why the extra costs? There’s a few main reasons:
If you’re expecting to have access to the source code in order to make your own customizations, make sure it is clearly stated in the licensing agreement.
For many types of SaaS applications–including ERP options, there is a growing trend toward usage related pricing models. In usage based models, your pricing tier may be determined by your bandwidth or data storage consumption, for example.
But consumption of network resources isn’t the only usage metric which SaaS providers use when determining pricing. While it’s less common in full-fledged ERP systems, many task-specific applications will assign costs related to creating new records in the system.
Some examples of usage related pricing models include:
There are pros and cons related to usage based pricing. On one hand, there is something that satisfies our sense of equitability to pay only for what we use. On the other hand, usage based pricing creates less predictable out-of-pocket costs from a cash flow management perspective.
Another software licensing issue that is particularly relevant for SaaS buyers is data ownership. In an InformationWeek.com study, 31% of the survey takers who had not adopted SaaS solutions indicated that concerns over data ownership were one of the reasons for their reluctance.
In fact, at some point, generally every software buyer generally will ask their SaaS vendor: “I understand I’m essentially renting the use of software, but do I still own the data?”
The easy answer to the question is yes–in the sense that any reputable SaaS based ERP solution will allow for data export of records. The software license agreement will specify this capability.
But don’t overestimate the scope of this licensing language. Not every program’s export features are equally robust. Sure, with any program, you’ll be able to export things like invoice data showing customer numbers, invoice dollar amounts, line items and so on. But what if you’ve established complicated conditional business logic for approvals processes in your supply chain management? It’s considerably less likely this sort of settings and permissions oriented data will be transferable.
There are some other important contractual issues that surround the larger topic of data ownership as well. In a software licensing agreement, the contract should specify where and how data is backed up. Will your data share physical server resources with other customers? How will your data be eradicated once you’ve ended the service contract? These are questions your contract should answer.
Things change. It’s a simple fact of life.
When it comes to your ERP software needs, it’s easy to predict that you’re likely to eventually need to increase or decrease:
It’s important to find out what your licensing agreement says about pricing related to these changes. An anecdote from an IT executive writing for InformationWeek.com about a recent major software purchase helps to shed light on why:
For each vendor, we were looking at an 80 percent to 90 percent discount from the list price. In what other market is an 80 percent discount the norm? “This new Lexus lists for $70,000, but we can get you into it for $14,000!” Let me guess: We now have to hunt through the contract for future fees that are based on the list price, right? More time spent negotiating maintenance and other aspects of the contract to avoid dependence on the five-times-higher list price.
The important question to ask is, when you need to add users or a new module, will you be paying that list price or the rate you originally contracted at? After all, once you’ve gone through the work of installing and running the software for a while, your negotiating leverage is considerably diminished.