Perhaps more frequently known as a Request for Proposal (RFP), an Invitation to Tender (ITT) or a Statement of User Requirements (SOUR), a written statement of what a new system is required to deliver is essential to achievement of a successful project but is one of the hardest things to do.
Many companies leave the ERP RFP task to external ERP consultants, but that is not always a good idea. If using general management consultants, they can find that those consultants burn up a lot of the budget to create a document that is actually of very limited value. Additionally, many of those consultants have close relationships with specific ERP providers and will be tempted to write requirements specifications that guide the client towards their partner's system.
Companies should be looking at writing the document themselves – even though it is a good idea for them to engage specialist ERP consultants to give them initial advice on how to write it and then to refine it and to support them during the selection process. Once completed, the document becomes a vital component in a company's armory when they have dealings with prospective suppliers of a system, and later with the implementation consultants.
Though it cannot completely replace face-to-face contact with systems integrators (SIs) and potential suppliers, it helps immensely to focus the clients' minds on what they actually want from a new system. And the clarity that results from that will play a very significant part in a successful implementation. It may help crystalize your evaluation of Deloitte, Accenture, Capgemini and other ERP system integrators.
The document should not be a list of generalities such as "improved management information" or "increased service levels," but neither should it be so detailed that prospective bidders give up on trying to read it. The length of the document that should be sent to prospective bidders is very much dependent upon the size of the contract being offered.
When looking for a multi-million-dollar system as a streamlined ERP software selection process, it is reasonable to expect the bidders to do a lot of work to win the business. In this case, a 200-page document would not be unreasonable, but a small company with thirty thousand dollars to spend cannot expect more than one or two days of the bidder's time – which probably means 10-20 pages at most.
Give such a bidder a document that takes several days or weeks to respond to and their cost of sale will be higher than their anticipated profit. A detailed document may be needed for assessment purposes, but companies can consider a cut down version for external purposes.
Formal requirements documents have unfortunately fallen out of favor in recent years. The reason is that so many of them were bad and unfit for purpose. Problems included:
The other big problem with these documents is that they have traditionally been page upon page of tick boxes. But there is a weakness in this and that is that such questions are easy for prospective suppliers to misinterpret or to 'interpret advantageously' and so it is almost impossible for such questions to uncover the truth about a system's capabilities. For that reason, the document should contain questions that begin, “How..?”. For example; they shouldn't ask, “Is your system multi-currency?”, but should ask: “How does your system support multi-currency transactions?”.
Now the down-side to this, of course, is that the answers, being more detailed, take more time for the bidder to write and more time for the customer to read. There must then be fewer questions on the RFP/ITT/SOUR. In actuality, this is not really a problem. Old-fashioned documents were full of questions such as "How many characters are there in the customer name field?" and "Is there a field for the buyer's initials on the stock file?" so let's consider what a useful (to both customer and bidder) RFP/ITT/SOUR should look like.
Following an introduction (of no more than one page) that describes the company, how it operates and what is important to it, each functional area should specify what they need from the new system. This should not be a list of database fields, nor a list of required reports, but should describe the way that each department works and the business processes that the new system must support. They should then ask the prospective bidders how their system can contribute to those objectives. The document must be specific about what needs to be done but should not specify how it is to be done.
One very common mistake is to document the current system and use that as a basis of the requirements spec. If we bought cars that way, we would still be driving Model 'T' Fords. When companies use their existing system as a template, they can find themselves too much constrained by their previous experiences. But, when they tell prospective bidders what they are trying to achieve, as opposed to what they are trying to do, then they, having implemented systems at many other companies and knowing their software well, may be able to suggest alternative and better ways of doing things.
Companies also need to ensure that the document lists all of their business processes and not just the ones that are causing problems today. When writing the document, it is only too easy to forget the things that are working fine and assume that the new system will do all that the old system did. Even if the new system is coming from the same supplier as their old one, this is almost certainly not the case. The rule is that nothing is there until it is confirmed to be there. The name on the package might be the same but the content almost certainly differs.
So, in conclusion; a good systems spec has the following benefits:
That makes it a pretty useful document and, if companies need help to pull it together, they will find that to be a very small but very worthwhile investment.
One last thought: having created the requirements specification, it is essential that it be agreed and signed-off by the senior management of all the departments that it covers. If any of them disagrees with the content, or even with the aim of implementing ERP, now is the time to say so: it is not possible to implement ERP successfully without the total commitment of the C-suite but, with everyone on board, companies will find that they can move mountains.
Having written the RFP/ITT/SOUR, the next stages are sending it to prospective suppliers and assessing their responses. Good ERP consultants can give useful advice on how to do these, but a future blog will address these topics also.
