# libtechrfp

### Site Tools

how_to_use_the_ukcs

# Differences

This shows you the differences between two versions of the page.

 — how_to_use_the_ukcs [2018/06/26 20:25] (current) Line 1: Line 1: + **How to use the UKCS**\\ ​ + ====== Table of Contents ====== + [[#toc0| ]][[#​checklist_model|Checklist model]][[#​checklist_model-Requirement number|Requirement number]][[#​checklist_model-Type|Type]][[#​toc4| ]][[#​checklist_model-Requirement|Requirement]][[#​checklist_model-Requirement-Importance|Importance]][[#​checklist_model-Requirement-Compliance|Compliance]]\\ ​ The UKCS has been developed to reduce the effort involved in specifying standard functionality which is available on all library management systems (LMSs). It was compiled in consultation with a number of LMS suppliers who agreed a core set of requirements,​ together with a variant set to meet the needs of differing market sectors. The model agreed with suppliers for the UKCS was a checklist of basic functions which could be expected on any LMS. The checklist is intended to form one part of an Operational Requirement (OR), which is normally included in an Invitation To Tender (ITT) in formal procurement procedures. However, it can also be used in less formal procedures as a simple checklist of features.\\ \\  It is important to recognise that the UKCS is not an accreditation scheme, and whilst suppliers have agreed a core set of functions which should be available on any LMS, validation of individual supplier responses remains the responsibility of individual libraries. It will still be necessary to evaluate core functionality at supplier demonstrations and site visits – for example, libraries will want to ensure a sensible workflow for the issue process, where a ‘full compliance’ response has been given in the core specification. Libraries will not, however, have to spend time specifying basic functionality in detail or evaluating equally detailed responses, but can concentrate on areas of functionality which are not provided on all systems – in other words, on the //​differences//​ between systems. \\ \\  The UKCS should not be regarded as a generic specification,​ but rather as the core of a complete specification,​ which will take into account both local requirements and the relative importance of the core requirements. It is essential, therefore, that libraries review the requirements in the UKCS, paying particular attention to the Importance column (explained below), rather than just including the UKCS as an ‘added extra’. This will also help avoid duplication of requirements and wasted effort. \\ \\  The UKCS is, by definition, geared towards UK market requirements. Terminology is as used in the UK (e.g. supplier rather than vendor, reservation rather than hold). Where necessary, compliance is required with UK law, e.g. Disability Discrimination Act. \\ + =====   ===== + ====== Checklist model ====== + \\  The UKCS takes the form of a checklist which details core functionality for the following main functional areas:\\ \\ + + * Bibliographic database management + + * OPAC and end user services + + * Circulation control + + * Acquisitions + + * Serials control + + * Document delivery and inter-library loans + + * Management information + The checklist comprises the following columns: \\ \\ + ===== Requirement number ===== + \\  Each number is prefixed by R for core requirement or V for variant requirement. Libraries should not change the numbering or text of these requirements – this is because suppliers will have set up standard responses to the UKCS.\\ \\  Additional requirements or changes to the standard requirements for these functional areas should be specified in a separate section of the OR. Other requirements,​ such as technical, training and support etc, should also be covered separately (see below for what is not covered). \\ \\ + ===== Type ===== + =====   ===== + For variant requirements,​ the type of library is given: A (Academic), P (Public) and/or S (Special).\\ \\ + ===== Requirement ===== + \\  This column contains a text description of the function.\\ \\ + ==== //​Importance//​ ==== + \\  There is provision for libraries to indicate the importance of each requirement. The following values are suggested:​\\ \\  3 Important (or mandatory)\\ ​ 2 Highly desirable \\  1 Desirable\\ ​ 0 Not required (or not applicable).\\ \\  The reason for the zero value is for libraries to indicate to suppliers where a core or variant requirement is not required or not applicable. This allows for the checklist to be used by a wide variety of libraries which may place differing importance on these requirements,​ or indeed not need them at all. This can also be used to indicate where a complete functional area is not required – for example, if the Document Delivery function is not needed, all requirements in this section could be marked zero and suppliers instructed not to respond to this section. \\ \\ **It is important that requirements are flagged as not required or not applicable, even if the other values are not used.** This is so that suppliers will know they do not have to respond to the requirement. Academic libraries, for example, should flag any variant public library requirements (P) as not applicable.\\ \\ + ==== //​Compliance//​ ==== + \\  This column should be left blank for suppliers to indicate their compliance with each requirement. The form of the supplier’s response should be defined by the library and made clear in the instructions to suppliers. One of the following forms of response is suggested: \\ \\  1) Yes/No response – this is the simplest form of response for the checklist approach. Suppliers should be instructed that ‘Yes’ means fully supported and on general release.\\ \\  OR\\ \\  2) Response codes – the following codes are suggested: \\ \\  A Fully supported and on general release \\  B Partially supported and on general release\\ ​ C Planned for a future release\\ ​ D Not supported\\ \\  Additional information – libraries can indicate in their instructions to suppliers if they want suppliers to provide additional information along with the compliance rating. Some libraries find it helpful to have additional information,​ perhaps explaining how a particular requirement is met. It should be remembered, however, that all these responses have to be read (!) and many of the core requirements can be regarded as standard. A compromise might be to flag a requirement (e.g. by an asterisk) if additional information is required. \\ \\  Suppliers can also, at the discretion of the library, be invited to add their own comments, if they feel a particular response needs further clarification,​ e.g. if a ‘partially supported’ code is used, or a date if planned for a future release.\\ \\  Further instances where additional information can be useful are detailed below. \\ \\  Evaluating suppliers’ responses is one of the most time-consuming parts of the procurement process, and it is often difficult to differentiate between systems, particularly at the functional level. \\  A large number of the core requirements will be available on all library systems, and the differences may lie in newer aspects of functionality or local requirements,​ which will be specified separately. The advantage of the UKCS is that it allows libraries to concentrate on critical and important aspects of functionality,​ over and above the core list, safe in the knowledge that the basic functionality is covered. It is also important to recognise that the functional evaluation is only one part of the process, and other evaluation criteria will be equally, if not more, important, such as supplier viability, technical aspects and, not least, cost.