A decade ago it was common practice for businesses to employ a consultant to write a Request for Proposal (RFP) as the basis for the selection of Enterprise Resource Planning (ERP) software. The usual format of this document was a series of questions purporting to define the required system. I have seen some of these run to 2,000 such questions. Prospective suppliers were expected to respond to questions that ranged from the trivial (Does the general ledger have debits and credits?) to the complex (Can the system handle part shipments, back orders, drop shipments and back to back ordering?). The vendor was asked to reply yes, no, or needs a modification. This approach was unsatisfactory for both the buyer and the vendor and has largely been abandoned. However, it may be useful to review the deficiencies of the practice as it still occasionally rears its head.
Business systems are too complex an interaction of processes to be defined by lineal statements. Vendors were frequently left with the frustration that some of the requirements were contradictory, many were incompletely defined or ambiguous, and there were often omissions. In the limited, and often one directional nature of the tendering process, it was not possible to explain that a better solution than the one requested was available. The adversarial nature of the initial relationship between the client with his consultant and the vendor often continued into the project and was a significant cause for its subsequent failure.
The fundamental flaw in the RFP process is to believe that the system can be defined completely before the software is chosen, before the implementation team is assembled and before the client staff are given the opportunity to contribute meaningfully.
The purpose of a new business system is the provision of improved processes for the efficient running of the business, and the resultant delivery of business benefits. To be effective, this needs to take advantage of all the intellectual property that is embodied in the chosen software; all the ideas from its developers and those firms who are already using it; the knowledge of the implementation team who are familiar with this software and ERP systems in general from their previous experiences; and the client staff’s knowledge of how the firm functions and how they would like it to function better. The development of these improved processes proceeds during the implementation phase. They cannot be defined in an RFP. The details cannot be known at that stage.
Yet clearly the client needs some guidance. My colleague Peter Hill developed a far more practical approach. I call it the Aristotle method after the great philosopher who specified that definition required genus plusdifferentia; a dog is a four legged animal that barks.
Firstly, he (that is Peter not Aristotle) defined the system in generic terms (e.g. an ERP System covering finance, sales order processing, purchasing, inventory control, warehouse management, sales analysis etc.). Secondly he defined those matters which might differentiate one system from another or eliminate some prospective vendors from the list (e.g. Does the system cope with import costing? foreign currency? back orders? EDI? etc.). He worked with the client to define the absolutely must have requirements for both the system and the vendor. For example, a client may state that it is vital that the system is already installed in five similar businesses. Any vendor whose system does not meet that requirement is eliminated. In most cases he was able to limit this list to fewer than twenty items and these formed a Request for Information (RFI). Having thus defined in short order which vendors could comply, he then helped the client to choose the most appropriate combination of system and vendor on the basis of relationship factors (references, reputation, location, affability, cultural fit etc.) and price.
The keys to the success of this approach are: to have the client make hard decisions about the must have (i.e. knock-out) requirements; to have the client make decisions about their preferred approach based on their schedule, cost, and requirement constraints (have they the time and resources to evaluate in detail a short list of two to four vendors or will they choose a preferred vendor from the RFI and work with that vendor as their preferred choice, only moving to their second choice if for any reason the preferred vendor/system proves unsatisfactory?); and finally to deal honestly with all the vendors so that they can understand their chances of success and invest accordingly.
This is not only a more cost effective process but one that is more likely to succeed. The client does not waste time and expense on the development of the flawed RFP and he begins the project in a trusting and cooperative relationship with the vendor.
Finally, it is worth emphasizing that much of the success of the new system will depend on how well the staff adapt to it. That is more likely to happen if they play a significant role in the selection process and the implementation.
