The invitation to tender process for ERP

This the first in a series of four blogs that looks at writing ITTs, reviewing them, verifying responses via a vendor demonstration and finally placing a contract. They are important because when ERP implementations go wrong, they usually start going wrong in the very early days, and one of the things done in the very early days is specifying what the new system has to do; so there may well be a connection.

All ERP professionals agree that a written statement of what a new ERP system is required to deliver is essential to the achievement of a successful project but it is also one of the hardest things to do. Formal requirements documents, more commonly known as Invitations to Tender (ITTs) although also called Statements of User Requirements (SOURs) or Requests for Quotation (RFQs), have fallen out of favor in recent years, probably because so many of them were bad and unfit for purpose. Problems included:

• An inappropriate level of detail; being either too detailed or too sketchy.
• A failure to reflect the business's true wants and needs. Many documents were, in fact, taken from a 'stock' of previously-used ITTs, cut and pasted into a notionally bespoke document.
• A failure to look into the future to consider where the business is likely to be going in the medium term.

These documents have traditionally been page upon page of tick boxes, and the problem when evaluating a response to an ITT that has questions along the lines of "Is your system multi-currency?", is knowing what a 'yes' answer actually means. Professional salespeople don't tell lies but some can be tempted to “interpret questions advantageously”, so a good ITT needs to come at the problem from a totally different angle. It would clearly be better to ask, "How does your system handle multi-currency transactions?". So let's consider what a useful (to both customer and bidder) ITT should look like.

Compare manufacturing ERP with our free comparison tool

It is important to say that the length of the document sent to prospective bidders is very much dependent upon the size of the contract being offered. At the one extreme, it should not be a list of generalities such as "improved management information" or "increased service levels" but, on the other hand, it should not be so detailed that prospective bidders give up on trying to read it.

When looking for a multi-million dollar system, it is reasonable to expect the bidders to do a lot of work to win the business but a small company with thirty thousand dollars to spend cannot expect more than a few days of a vendor's time. 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. If a detailed document is needed for assessment purposes, then a cut-down version can be considered for external purposes but, as a guide, it would be reasonable to hand a 200-page document to a bidder for a $10 million system but, for a $30,000 system it would not be realistic to expect anyone to read and respond to a document of more than twenty pages or so. Likewise, it is reasonable to expect a detailed response for a large system but not for a small one. 

The ITT should begin with an introduction to describe the business and what it does. If there is a requirement to link to other systems, and these are needs and not nice-to-haves, then there should be brief details of these other systems. The next section should show the following:

• An indication of budget. If the budget is $10 million, small suppliers will know not to waste their time and, by doing so, not waste yours. If the budget is $10,000 then large outfits will know not to waste their time and, by doing so, not waste yours.
• Projected timescales. Perhaps the new system has to be in and ready for the beginning of the new financial year, for example.
• Anything that would be a genuine show-stopper. For example, your French subsidiary needs screens in French, or you are part of a group of companies and you must stick to corporate standards on databases etc. Anything that is listed as being non-negotiable must, however, be justified to the project sponsor and to the team.

Following this introduction, 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 system must support. It 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 requirements. If we bought cars that way, we would still be driving Model 'T' Fords and if companies get into too much detail, they can find themselves too much constrained by their previous experiences. But, if 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. We can all, in writing such documents, too easily 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 the old one, this is almost certainly not the case. The rule is that nothing is there until it has been verified as being there. No functionality is there until confirmed. Nothing can be assumed or taken for granted. 

The next article in the series looks at how responses to an ITT should be assessed.