A Model Rfp for an Automated Library System

INTRODUCTION The decision to procure an automated library system is one of the most significant decisions librarians make, not only because it involves a great deal of money, but also because it is a highly visible undertaking. Failure can be costly, politically as well as financially. This report describes the planning process, including the role of library staff. The first part of this report discusses the procurement process, including initial planning and specification development. The balance of this issue is a model RFP (Request for Proposals) comprising: instructions to bidders; general system requirements; detailed functional requirements; minimum hardware configuration; vendor support; and acceptance testing and ongoing reliability requirements. An RFP seeks proposals, rather than just a price quotation. The assumption is that each vendor will propose an already developed system which may not meet every requirement in the RFP. A library then chooses the vendor which offers the optimum combination of conformity to the requirements, price, and other evaluation criteria established by the library. In contrast, an RFQ (Request for Quotation) seeks to have the vendor provide exactly what is sought, with the price and other evaluation criteria being the basis for vendor selection. RFQs are increasingly rare as it is costly to develop a customized system or modify an off-the-shelf system to meet all of a library's requirements. An RFB (Request for Bids) is another name for an RFQ, although some municipal purchasing departments use the term in lieu of RFP. An RFI (Request for Information) seeks a response to requirements when a library does not yet have the funds to make a purchase. Responses to RFIs usually are much less complete than responses to RFPs, and the responses usually are not legally binding. While the model RFP assumes a mid-size public library, any type or size of library interested in procuring a multi-user, multi-function automated library system can adapt the RFP for its use. While the model is suitable for specifying a UNIX or NT-based system running on a server, it is not recommended for specifying products using the DOS or Windows xx operating system, whether on a single PC or a PC-LAN. The model is comprehensive and may include functionality which a library may not require or cannot afford. In the former case, the elements should be deleted; in the latter case, they should be changed to options just in case the prices in the proposals are lower than expected. Staff who are not familiar with the library automation industry should do some background reading before beginning work on an RFP. The author's Library Administrator's Automation Handbook (Medford, NJ: Information Today, Inc., 1997) is a suitable introduction. Thereafter, consulting issues of Library Technology Reports, a publication of the American Library Association, for more current and detailed information is a good idea. At least two monograph-length issues each year are devoted to library automation. PROCUREMENT PROCESS The procurement of an automated library system requires a more complex, time-consuming, and costly planning process than any activity other than developing a building program. In addition to significant budgetary implications, there may be major changes entailed in automating. These can include organizational changes, revisions in library policies and procedures, changes in the attitudes of both staff and patrons, and undertaking complex contractual obligations. Automation is too complex and costly to undertake without first engaging in extensive investigation, discussion, and decision-making. RISKS IN AUTOMATING Automation also involves taking chances, even if the library has identified all the possible outcomes and made a careful estimate of the probability of each outcome, it is not possible to predict what will happen in every case. …