Creating a 'request for proposal.'

Nation's Restaurant News, Jan 13, 1992 by Robert Grimes

In the last column we examined the primary steps you need to take to select the right system for your operation. Let us take a moment and quickly review these steps before we continue with our examination of the selection process.

In the first step we performed a "Needs Analysis." During the analysis we listed the operational and informational needs of our operation, selecting which of the needs we desired to be automated.

Next, we prioritized the requirements list, identifying those requirements we deemed most important to be automated. These "top" requirements are the ones we shall use to judge the systems we select in the alter phases of the process.

Once the prioritizing step in completed, we collected information on the available foodservice systems. The information was gathered by attending industry conference or reviewing the industry guides and periodicals. We checked the functions of each of the systems and compared the functions with our requirements list.

Those systems that did not meet our needs were removed from further review, thus leaving us with a list of systems that best met our needs. That brings us to the topic of this article -- an examination of the stops we need to take to finish the selection process.

Normally the next step is to formalize the proceedings and create a Request for Proposal to be delivered to those vendors that have a product that comes "close" to our requirements.

The main purpose of the RFP is to determine if any of the vendors should be selected as the "vendor of choice."

As stated in the last article, a RFP is a formal request to the vendors to submit a bid for using their system. Normally a RFP's format is divided into five main sections: (1) general information, (2) functional requirements, (3) hardware and software requirements, (4) vendor profile, and (5) cost and fees.

The first section, general information, has two objectives. It should inform the vendor about your operation and it should state the general rules for the vendor's response.

The first objective, informing the vendor about your operation, is to give the vendor a good indication if his or her product matches the style of foodservice operation you have. It is very possible that the system functionally can do what you want but is not best suited for your type of service.

For example, a particular point-of-sale system may give you all the operational functions you desire but will not "look right" in the dining room atmosphere you have created. Vice versa, a fine dining system may provide the functions you are expecting but is not best suited for the turnover of a quick-service operation. If the vendor is not informed of the style and volume of your foodservice operation, he or she may not present the proper system or model of system that best suits your needs.

The second objective of the first section is to state the rules the vendor should follow in responding to your request. It should provide details on such items as: who their contacts should be, when and how you are going to notify the vendors of a decision and what kind of expectations you have about the response. In addition, you should address how they should answer the response. For instance, if you are asking them specific questions, you may want to ask the vendor to respond exactly to those questions rather than giving you company brochures and other material.

It is a common practice, for example, to provide a questionnaire for the vendor to complete as part of their response to you. The results of the vendor information should be so that you can fairly and justly compare one system with another.

There is no one way the vendors will respond to a RFP, and by defining the format and rules it helps the vendors to determine what you want.

The second section of the RFP specifies the functional and operational requirements that you are looking for. That is a detailed breakdown of the requirements list you compiled earlier in the process. However, this time you want to know not only if the system can complete a particular function but also how well it accomplishes the task.

For instance, if you are looking at POS systems, you might want to know items such as the number of servers the system can handle, the number of menu items it can store or the number of price look-up item it allows. In other words, what are the parameters of the system.

It is important that the vendor defines the outer limits of the system by the features themselves. In this manner you can determine if the system can grow with your operation as well as meet your current needs.

You should also question how many of the defined functions the system can do at the same time. In some instances the vendor may answer yes to your list of desired features but cannot provide all the features together. For example, if you need 1,000 menu items and you also need 100 servers, the system may be able to give you both features individually but not at the same time owing to some restrictions of the system.