Companies have differing software requirements; from CAD to payroll, and from project management to maintenance management. This article focuses on ERP because so many companies use it, but the ideas discussed can just as easily be applied to all those other systems.
History and experience tell us that implementing an ERP system successfully has a profound effect on a company’s performance. A good system not only allows things to be done more efficiently but also facilitates things that had previously not been possible at all. It’s no wonder that so many companies use ERP systems but, sadly, many implementations fail and even when they don’t, many, in fact most, companies are disappointed with what they get.
Often the problem is that good systems have been implemented badly, and many articles have been written to highlight problems such as:
- a lack of senior management commitment,
- inadequate change management,
- insufficient user buy-in,
- inappropriate cost-cutting, and
- using a second-rate selection and implementation team.
This looks at another problem; that companies don’t get what they expect because they don’t pick systems that are capable of delivering what they want.
Evaluating software is not always easy; especially if trying to do so without a good requirements document. It is certainly possible when looking at simple systems but, almost inevitably, when companies select large systems, such as Enterprise Resource Planning (ERP) or Warehouse Management System (WMS), without a written specification of what the system is required to do, things get missed.
Sitting in front of a salesperson, or at a demonstration, it is only natural that the things that are foremost in our minds are the things that happened recently; especially if these things were painful. That means that we can find ourselves looking for software that can handle the 1% of things that go wrong whilst ignoring the 99% that goes right. This can especially happen when the system being assessed is seen as an upgrade to a previously used system.
Surely, the new software will do all that the old system did but with new options and functionality added, what else can it do?
In reality, that is almost always not the case, even when the new system is coming from the old supplier. It is also true that, after a few years, people forget that elements of their old system may have been heavily modified or bespoke options added so that what they believe to be ‘standard’ features are actually anything but.
This danger is exacerbated when the system is required to straddle departmental boundaries and not all of the departments affected are part of the selection process: a good example of this would be an ERP system that is selected by one department only. More problematic is when a system is selected by a senior manager because “it worked well at my previous company”.
This can be a valid approach when looking at ‘single department’ systems but, when looking at ERP systems, it is usually dangerous to assume that senior managers, even IT managers, have a good and complete understanding of how other departments work and what they need. Now, if they do have a good knowledge of how all affected departments worked in their previous company, assuming that all departments in their new one work in exactly the same way (or should work in the same way) is, at best, unrealistic.
Even similar size companies in the same industry can have very different ideas of how they want to operate.
Functions of Software Systems
When questioned about the functionality of their systems, good salespeople won’t actually tell lies but they can be masters of ‘interpreting questions advantageously’. Regardless; it is not reasonable to expect that a system costing $50,000 can do all that a system costing $5 million can do and in fact, some systems sold as ERP are not actually ERP at all. Different companies have different ideas of how they want to operate and what they want their systems to do for them.
The only way for companies to get what they expect to get, and what they have paid for, is for them to specify very carefully what they want and to compare very carefully what they are offered against those specifications. To do that, they need to prepare a good requirements document (sometimes called an Invitation to Tender, Request for Proposals or Statement of User Requirements), to measure competing systems against that, and to write supplier responses to it into the final contract.
The problem now kicks in. Most requirements documents are not only not very good, they are frequently worthless. Before looking at what a good requirements document is, it is worth a few words on what is wrong with so many of them. Many companies often make two mistakes when writing requirements documents.
Some prepare a document that is just a series of yes/no tick boxes and others just list the data fields and reports that they expect to see in a new system. Tick boxes have a serious weakness, and that is that many questions cannot be properly answered with a simple yes or no. If the question is whether the system is ‘multi-currency’, it may be obvious to the person asking it just exactly what functionality they expect to see but, if the system’s authors disagree, there may be surprises in store.
When companies list the data fields that they want in the new system, they may consider it obvious that the functionality they are looking for will be behind those fields, but that is just an assumption. For example; specifying that there should be a credit limit field on the customer record doesn’t specify what they system is required to do if that limit is breached. As for reports; are two people ever likely to agree on what a ‘materials status report’ should be? This is a question that sometimes is not answered right away.
Advantages of Good Requirements
Having a good requirements document has multiple advantages. Apart from when looking at very simple systems, it is impossible to see and evaluate all the functionality that a particular customer wants during a demonstration. Part of the problem is that, the bigger a system is, the more functionality it will have but the more configuration it will need to make that functionality in the way that a particular customer wants.
Tier 1 systems can take weeks or even months to fully configure (and may also need enhancements or modifications) so, inevitably, at a demonstration or presentation, verbal promises have to be made in response to many questions.
Few companies nowadays have people who know shorthand, so recording everything that is said is a problem. Fortunately, there is an alternative to recording every word and that is for companies to write to, or e-mail, suppliers after the demonstration or presentation, along the lines of, “This is what we understood you to say. If our understanding is wrong, please advise us immediately in writing.” This is such an important thing not to forget.
Looking at what a good requirements document is; the first thing to say is that its length should reflect the expected value of the contract on order. If a company is in the market for a multi-million-dollar system, it is reasonable to expect bidders to respond to a document of several hundred pages but, if they are looking at systems costing just a few tens of thousands, that is not realistic. Either way, the document should start with a one-page overview of the company, with a brief summary of:
- Its line of business (e.g. ‘Manufacture of domestic electronics for the home and export markets’),
- Its approximate size, in terms of both turnover, number of order lines processed daily, and number of employees,
- The location of each business unit that will be accessing the system,
- Anticipated timescales (e.g. the system might be required to go live by a specific date),
- “Show stoppers”; i.e. things that the system absolutely must have, such as screens in specific foreign languages for overseas subsidiaries,
- Required response times; e.g. MRP must be able to be run within a given time, dispatch notes must be able to be produced within, say, 5 minutes of stock being allocated, etc.
Then each functional area that will be using the system should describe how they operate and what they need the system to facilitate. For example; a sales department might say things like:
- they hold different prices for different customers or types of customer (trade, retail etc.) in the customer’s own currency and need those prices to default automatically when entering orders,
- they need to reserve stock immediately on request for some customers,
- if there is insufficient stock on-hand when a customer phones, they need to see when new stock will be coming in whilst the customer is still on the phone, etc
There are several advantages to customers in having this type of document. One is that prospective suppliers have to be specific about what their systems can deliver. When responses are in writing (which they must be), these responses can be included in the eventual contract so that neither customer not supplier should have any surprises after the contract is signed. Lastly, the supplier’s responses will demonstrate how well they understand the customer’s requirements and business.
In the end, writing these kinds of questions, responding to them and evaluating those responses takes more time than just ticking boxes, so the number of questions that can be asked will be less than the hundreds or thousands that typically get asked in a ‘traditional’ requirements document, but that actually allows companies to focus on what really matters (does it really matter how many characters are available in the ‘Buyer’ field on the stock record?).
‘Traditional’ requirements documents have consistently resulted in second-rate purchase decisions. It is time to try something different. If you have questions regarding software selection decisions or digital transformation in general, please reach out to Third Stage directly.