Contents
1. INTRODUCTION ............................................................................ 1
1.1 A single Library Management System for Public Library Services in
Ireland ......................................................................................... 1
1.2 Governance ............................................................................. 1
2. BUSINESS CASE AND VISION ........................................................ 2
2.1 Library Management System (LMS) ............................................ 2
2.2 Mission and Vision of Irish Public Libraries ................................... 3
2.3 Current Library Management Systems and Technical Environments 4
2.4 Opportunity ............................................................................. 5
2.5 Cataloguing Standard ............................................................... 5
2.6 Co-operative working................................................................ 6
2.7 eBooks ................................................................................... 6
3. PROPOSED INFRASTRUCTURE ........................................................ 6
3.1 Introduction ............................................................................ 6
3.2 Scalability and Flexibility ........................................................... 7
3.3 Data hosting ............................................................................ 7
3.4 Open Standards ....................................................................... 7
3.5 Browser-based and cross-platform ............................................. 8
4. SCOPE OF TENDER ....................................................................... 8
5. QUALIFYING CRITERIA .................................................................. 8
6. AWARD CRITERIA ....................................................................... 10
6.1 Proceeding to Award Criteria Evaluation Stage ........................... 10
6.2 Clarifications .......................................................................... 10
6.3 Criteria and Weightings ........................................................... 11
6.4 Total Cost ............................................................................. 11
6.5 Understanding of ‘Implementation’ ........................................... 11
7. RESPONSE TO TENDER ................................................................ 12
Draft 9.2: Page i of 94

7.1 Organisational Details ............................................................. 12
7.2 Project Implementation and Management ................................. 16
7.3 Pricing .................................................................................. 18
7.4 Declarations .......................................................................... 20
8. Response to Functional Specification ............................................. 21
8.1 General Requirements ............................................................ 23
8.2 Acquisitions and title item management .................................... 26
8.3 Circulation/Reader Services - Staff Mediated ............................. 33
8.4 Serials (tracking magazine and newspaper holdings) .................. 44
8.5 Resource discovery public user interfaces .................................. 47
8.6 Management Information and Reports ...................................... 51
8.7 Database Management/Hosting (Cloud etc.) .............................. 56
8.8 Document delivery and inter-library loans ................................. 62
8.9 Fallback, Backup and Disaster Recovery .................................... 64
8.10 Security .............................................................................. 65
8.11 Data Migration ..................................................................... 66
8.12 Open standards, data, architecture & development strategy ...... 67
8.13 Support, Product Lifecycle, Enhancements, Roadmap, SLA ........ 69
8. 14 Training ............................................................................. 72
8.15 Consortium Working ............................................................. 73
Appendix A – Article 45 Declaration (non-witnessed version) ............... 74
Appendix B: Self Declaration of Financial and Economic Capacity .......... 77
Appendix C: Self Declaration of Quality Assurance Systems, Health and
Safety Systems and Business Continuity Plan ..................................... 79
Appendix D – Declaration Re Statutory Obligations ............................. 80
Appendix E– Notes for Tenderers ...................................................... 81
Appendix F – Irish Library Authorities data 2012 ................................ 89
Appendix G - Current Library Management Systems ........................... 91
Draft 9.2: Page ii of 94

1.1 A single Library Management System for Public Library
Services in Ireland
Public library services in Ireland are provided at present by thirty-two library authorities. Details of the public library services are given in
Appendix F.
The Department of the Environment, Community and Local Government; the Local Government Management Agency, and the City and County
Managers’ Association have agreed that as part of the new national strategy for public libraries a shared services approach to a single library management system for all local authority public libraries will be implemented.
The national single LMS will include a single shared library catalogue, facilitate a single national library membership card and provide the capacity for shared acquisitions, management and integration of print and digital material.
The system will be procured by the Local Government Management
Agency (LGMA) acting on behalf of Irish local authorities and will be managed jointly by Dublin City Council and South Dublin County Council on behalf of a Project Board.
The selected LMS will be implemented in the four Dublin authorities and
Kildare County Council, and subsequently in other library authorities on a phased basis.
1.2 Governance
The Library Management System and Services Governance Board, with the secretariat provided by Libraries Development, LGMA, will have overall responsibility for the Project.
Draft 9.2: Page 1 of 94

A Project Team, including an LMS Manager (provided by the vendor) and a
Project Liaison Officer (provided by a library authority) will be responsible for implementation and management, with the support of an implementation group consisting of the city and county librarians of the four Dublin authorities and Kildare authority. It is envisaged that as each library authority comes to join the system, the relevant city/county librarian will join the implementation group. This will give each library authority an appropriate level of communication with the Project Team.
The Project Manager, reporting to the The Library Management System and Services Governance Board, will retain overall control of all aspects of system design and development throughout the lifetime of the project.
Rules for dealing with exceptions, meeting local needs and requests for change, and the overall direction of the project will be established as soon as a supplier is selected.
2.1 Library Management System (LMS)
Typically the technical heart of library service delivery has been the library management system (LMS) or integrated library system (ILS) which integrates processes and work flows within one system. These processes include:
Acquisitions – ordering, receipting and cataloguing stock items, managing library stock budgets, etc
Circulations – issuing and discharging items at the library desks and by self-service; managing reservations, including shelf-checks; managing borrower accounts and transactions; fines and charges; etc
Readers’ Services – An Online Public Access Catalogue (OPAC) permits customers to enquire about stock, place reservations, renew loans, etc
Management Information – statistics on system transactions, borrower information, etc
Draft 9.2: Page 2 of 94

Authentication – the library management system is used to authenticate users of other services such as public access PCs, online services, etc
2.2 Mission and Vision of Irish Public Libraries
Libraries are cornerstones of their communities, enriching the fabric of
Ireland by providing equitable access to information, the resources and skills required for learning, and igniting discovery. Library services promote lifelong learning, the love of reading, the possibilities of technology, and the exploration of ideas, culture and knowledge in vibrant inclusive spaces.
Libraries are busier than ever. Since the Branching Out report of 1998, library service provision has greatly expanded from the traditional role of collection development, management and promotion to centres of learning, participation, and creativity. Library collections themselves have become more diverse and collection development and management now embraces a wide range of formats. Public libraries provide access to eBooks and to digitised content, both purchased and produced from the library’s own collections.
Libraries enhance the lives of their users by providing access to culture and through supporting business and entrepreneurship.
Public libraries support traditional literacy in new and innovative ways and have embraced the delivery of Information Literacy and ICT literacy training and development in many forms. These literacies support society and the growth of inclusion and democracy. Public libraries have expanded the opportunities for learning that they offer and will continue to adopt new and emerging technologies as part of a modern, relevant library service.
Public libraries will continue to provide targeted collections and programmes to meet the diverse needs of children and young people with a priority focus on literacy, numeracy and learning.
Draft 9.2: Page 3 of 94

Given the trend of greater numbers of older people in the population public libraries will continue to deliver and develop services to meet the demands of older users. Older people will be included in all information and cultural programming activities.
Libraries have traditionally been leaders in using technology to deliver customer services and business processes. In no small way has this allowed libraries to increase service levels and embrace expanded roles in support of local government objectives. Public libraries will continue to embrace new technologies so as to continue to deliver effective, efficient customer-focused library services which meet the information, recreational, educational, cultural and heritage needs of customers.
From an ICT perspective libraries vision for the future includes:
Seeking to implement open data and open standards in order to simplify flexibility and development.
Facilitating Government policy in relation to co-operative working, shared services and consortia.
Applying Government policy on Cloud Computing at the earliest opportunity.
Hosting LMS data in the Government Cloud wherever possible.
Containing costs and saving money.
Delivering on a National Library Card.
Offering a single National Catalogue.
Moving to current library cataloguing standards to facilitate interlibrary co-operation.
Delivering Discovery services which will uncover all the riches the library services have to offer to customers from catalogues, databases and online services via a single search.
2.3 Current Library Management Systems and Technical
Environments
The library management system currently operated by the four Dublin library authorities is Axiell’s Galaxy and Open Galaxy which is provided and operated as four separate software instances on four separate Sun
Unix servers with Ingres as DBMS - along with four separate instances of
Axiell’s Viewpoint OPAC on four Viewpoint servers and three instances of
Artemis MI on three Artemis servers.
Draft 9.2: Page 4 of 94

Twenty-four library authorities use the Horizon LMS; three use SirsiDynix
Symphony, and one uses Millennium, all individual installations on separate servers. (Details of current LMSs are in Appendix G.)
A number of other products have been added over the years by different authorities to assist in delivering enhanced customer services and improved workflows. These include:
PCRes to manage customer take up of public access PCs
LPTOne to manage customer printing from public access PCs along with photocopying
BlueSocket Wi-Fi and wireless printing provision
Smartphone-friendly version of the catalogue
BookStream to facilitate addition of stock buys to the system.
Security Certificates on OPAC to deliver HTTPS service
e-Book service from OverDrive
Considerable effort is required to manage and integrate these services from multiple vendors. What is needed even more into the future is a system that is more readily interoperable with these third party solutions, i.e. a more ‘open’ solution.
2.4 Opportunity
The opportunity now clearly presents itself to acquire a new system, to yield savings in recurring direct Library IS costs and provide enhanced services to the public.
2.5 Cataloguing Standard
The four Dublin authorities still use UKMARC standard, as their current library management system does not support MARC 21. Other Irish library authorities use MARC 21. Neither Functional Requirements for
Draft 9.2: Page 5 of 94

Bibliographic Records (FRBR) 1 nor Resource Description and Access
(RDA) 2 is catered for in the current systems.
2.6 Co-operative working
Library services have traditionally worked co-operatively and the project assumes this will continue with all library authorities. A robust governance agreement will be established to ensure effective and cooperative working. The project team and project board have demonstrated their willingness and ability to work together.
2.7 eBooks
We are seeking a library systems vendor that can take an active role in developing a new generation of services for ebooks in the areas of business models, technologies and services so as to deliver a seamless experience for the user, a unified resource management approach for library staff and, permit the full range of ebooks to be made available for lending through public libraries. We recognise the latter in particular needs all parties in the ebook ecosystem to work together. We therefore expect the selected library system vendor to demonstrate how they are working with other stakeholders to deliver the kind of ebook solution our users and library staff should expect in the 21st century.
3.1 Introduction
Irish library authorities recognise that the nature and provision of library services is in a transitional phase. Traditional models of supply, support and development are being radically altered by the advent of cloud-based
1 Functional Requirements for Bibliographic Records* (FRBR) is a conceptual entity-relationship model developed by the International Federation of Library
Associations and Institutions (IFLA) that relates user tasks of retrieval and access in online library catalogues and bibliographic databases from a user’s perspective.
2 RDA: Resource Description and Access is the new standard for resource description and access designed for the digital world.
Draft 9.2: Page 6 of 94

applications and greater resource sharing. Irish library authorities wish to take advantage of the economies of scale potentially achievable through co-operative working and by moving to a managed hosted solution. At the same time we are interested in the improvements to existing services that new technologies and the concepts of Application-as-a-Service (AaaS) and
Software-as-a-Service (SaaS) can offer.
3.2 Scalability and Flexibility
The selected platform should be scalable so as to accommodate all Irish library authorities and be flexible enough to facilitate library authorities operating on a regional or county library service basis to deliver specified local borrowing and inter-library loan arrangements and to customize the staff- and public-facing functionality and appearance of the system as required.
3.3 Data hosting
Irish public library authorities place considerable value on the user data which it holds and, in keeping with Government policy, prefers that in a cloud-based system all user data reside in a specified hosted cloud environment preferably under the management of an Irish public sector body. Detailed technical information about public sector hosting will be made available to the successful supplier.
3.4 Open Standards
Both the LGMA and the Irish Government are committed to supporting the aims and principles of Open Data, Standards and Access. The replacement library management system should therefore be fully compliant with all aspects of Open Data, Open Access and Open Standards wherever possible. It should be noted that the degree of support for these principles will be a major factor in determining the selection of a supplier and products and platforms will be vigorously examined in this regard.
Please refer to section 12 of the functional requirements for more detailed information.
Draft 9.2: Page 7 of 94

3.5 Browser-based and cross-platform
The system should ideally be fully browser-based and preferably be capable of providing full functionality to library staff through any internetconnected desktop, laptop, or tablet computer, irrespective of the device’s operating system or browser. The system should also provide services to the public via any internet-connected desktop, laptop, tablet, or smartphone device, irrespective of the device’s operating system or browser. Any restrictions in terms of web access speed limitations or in terms of device operating systems should be clearly identified by tenderers.
The LGMA invites tenders for the provision, commissioning and management of the single library management system in accordance with a service level agreement (to be agreed).
The contract will allow for the provision, commissioning and management on agreed terms of the system(s) to the four Dublin local authorities and
Kildare County Council initially and subsequently to all Irish library authorities on a phased basis as each library authority (or group of library authorities) seeks to replace existing systems.
This tender is using the open procedure for the award of this contract.
Therefore, while all interested parties may submit a tender, only those demonstrating that they have the required level of financial and technical capacity will have their tender considered. In order to demonstrate their eligibility, tenderers are required to satisfy the following requirements:
Economic and Financial Standing
Criterion: Eligibility Requirements
Rule: Must complete and sign the EU Declaration Form attached with this notice confirming if any of the situations listed in Article 45 of the Public Sector Directive 2004/18/EC applies to the tenderer.
Tenderers may be excluded from participation based on the responses made in the declaration. (See appendix A for nonwitnessed version.)
Scoring
Pass/Fail
Draft 9.2: Page 8 of 94

Criterion: Tax Clearance Certificate
Rule: Must submit a signed statement that the company and all proposed sub-Contractors (if applicable) are able to produce a valid
Tax Clearance Certificate in compliance with Circular (43) 2006 and that the certificate will be maintained for the duration of the contract and will be on a 12 month basis. OR Must submit a valid Tax
Clearance Certificate as stated above. (See appendix B for selfdeclaration)
Criterion: Turnover during the past three financial years
Rule: You must submit a statement confirming that your turnover exceeded €2m in any of the last three financial years ( 2010,2011,
2012), or pro-rata if more recently established, and that you will provide evidence of turnover and other financial information promptly on request at any time prior to the award decision being made.
(See appendix B for self-declaration)
Criterion: Profitability
Rule: Must submit details of level of profitability for the last three financial years. Must demonstrate that company was in profitability in the last year or in any one of the last three years. (See appendix
B for self-declaration.)
Criterion: Bankers Reference
Rule: Must submit statement confirming that your company holds a bank account and that you are currently in good standing with your bank. (See appendix B for self-declaration.)
Criterion: Insurances
Rule: Must submit statement confirming that your company has the following insurances in place:
Public Liability, Employer’s Liability, Product Liability and Professional
Indemnity
LGMA generally requires cover of:
€6.5 million in respect of public liability
€13 million in respect of employer’s liability
€6.5 million in respect of product liability
€1 million Professional Indemnity
OR
Must submit a statement confirming that should you be admitted to the framework, you are willing and able to raise your insurance cover to these levels (in cases where the existing cover levels are lower) and that you will maintain these levels for the duration of the framework.
(See appendix B for self-declaration.)
Technical Capacity
Criterion: Organisational Profile & Capacity
Rule: Must submit a statement showing details of organisational structure, staff turnover level, current manpower levels, skills base
(including a breakdown of the key positions/skills). The Educational and Professional Qualifications of the Applicant, Managerial Staff and
Staff responsible for the service must be included. Applicants must demonstrate adequate organisational resources to fulfil contract requirements.
Criterion: Previous Contracts
Rule: Must submit details of successful delivery of at least three contracts relating to the provision of library management systems and should include one site similar in scale to the proposed consortium. Details must include a description of the contracts in question, relevant live url(s), the value of the contract, the precise
Pass/Fail
Pass/Fail
Pass/Fail
Pass/Fail
Pass/Fail
Scoring
Pass/F ail
Pass/Fail
Draft 9.2: Page 9 of 94

services supplied and how the contract was managed. (See section
7.1.)
Criterion: Client Reference
Rule: Contact details of at least three clients, for whom library management systems have been provided, that may be contacted on a confidential basis in relation to this contract, must be submitted.
Details must include names, addresses, email address, and telephone numbers. (See section 7.1.)
Criterion: Quality Assurance systems in place
Rule: Must submit statement confirming that Quality Assurance systems are in place. (See appendix C for self-declaration.)
Criterion: Health & Safety systems in place
Rule: Must submit statement confirming that Health & Safety systems are in place. (See appendix C for self-declaration.)
Criterion: Business Continuity
Rule: Tenderers must declare that they have a business continuity
Pass/Fail
Pass/Fail
Pass/Fail
Pass/Fail plan in place and tenderers must declare that their business continuity plan is tested on a regular basis. (See appendix C for selfdeclaration.)
RESULT – QUALIFIED OR ELIMINATED FROM DETAILED TENDER
EVALUATION
QUALIFIED/
ELIMINATED
Note: Only those tenders meeting the above qualifying criteria will be considered for inclusion in the award process. Tenderers should also note the mandatory requirements set out in section 8 below.
6.1 Proceeding to Award Criteria Evaluation Stage
Each proposal that conforms to the Qualifying Criteria will be further evaluated according to the Award Criteria as described below.
6.2 Clarifications
During the evaluation period clarifications may be sought in writing
(including e-mail) from Tenderers. LGMA and its agents may at their discretion request meetings and/or reference site visits with individual
Tenderers during the evaluation period for the purposes of clarifying any aspect of the Tenderer’s proposal. It would be essential that the key personnel assigned to this contract should be available and present at any such meetings.
The selection panel may also visit reference sites without the presence of the tenderer.
Draft 9.2: Page 10 of 94

6.3 Criteria and Weightings
The contract will be awarded on the basis of the most economically advantageous tender and in accordance with the following award criteria and weightings:
A
Award Criteria Weightings
30%
Minimum
Percentage
60%
B
C
D
E
Functionality and Fitness for Purpose
See Section 8.1; 8.3-8.11; elements of
8.12, and 8.15.
Project Implementation and Management,
Support, SLA, Training. See Sections 7.1 –
7.2; elements of 8.12; 8.13.1; 8.13.3;
8.14.
Product Lifecycle, Enhancements,
Roadmap, Open Standards, Data,
Architecture and Development Strategy.
See sections 8.12 and 8.13.2
Ordering/Processing Efficiencies derived from the automated Acquisition of all forms of Bibliographic and Enhanced Data e.g. MARC records, Reviews, Book
Jackets, Summaries etc. See section 8.2.
Ultimate Cost
See Section 7.3 A-G
20%
10%
10%
30%
60%
60%
Not
Applicable
NOTE: Tenderers should note that they must achieve a minimum rating of for each of the individual qualitative criteria (A) to (C) in order to avoid elimination from the competition.
6.4 Total Cost
Marks will be awarded for the total cost for implementation of the system to serve 100% of the population as submitted in row H of the pricing table in section 7.3. Marks will be awarded in inverse proportion to the lowest valid total cost. For example, a total cost which is 20% above the lowest valid total cost will receive 100/120 of the maximum marks.
6.5 Understanding of ‘Implementation’
In relation to 6.4 above ‘implementation’ means that the LMS is in operation in the relevant local authorities to the extent that library services can be delivered to the public to the expected standard and that
inter alia the acquisitions, cataloguing, circulations, and OPAC modules are fully operational.
Draft 9.2: Page 11 of 94

Respondents must explain in detail how their proposed service solution addresses the requirements of the tender and should provide all the information requested in the following sections and in section 8.
Where a group of undertakings submit a tender in response to this contract notice the LGMA will deal with all matters relating to this public procurement competition through the entity which will carry overall responsibility for the performance of the contract only (“Prime
Contractor”), irrespective of whether or not tasks are to be performed by a subcontractor and/or consortium members. The Tenderer must clearly set out: a) The full legal name of the Prime Contractor together with its registered business address (where applicable), registered business name (where applicable), company registration number (where applicable), telephone and e-mail contact details; b) The names of all subcontractors and/or consortium members who will be involved in the provision of the contract; c) A description of the role to be fulfilled by each subcontractor and/or consortium member; and d) The name, title, telephone number, postal address, and e-mail address of the nominated contact person authorised to represent the Prime Contractor, within the organisation of the Prime
Contractor, to whom all communications shall be directed and accepted until this public procurement competition has been completed or terminated. Correspondence from any other person
(including from any other subcontractor and/or consortium member) will not be accepted, acknowledged or responded to.
7.1 Organisational Details
7.1.1 Contact details and Organisational Profile
Name of Tenderer:
Contact person for this tender
Draft 9.2: Page 12 of 94

Address
Email:
Telephone
7.1.2 Organisational Structure
7.1.3 Staff Turnover
Year
% Turnover
2012
7.1.4 Current Manpower Levels
Permanent
Temporary/Contract
Total
2011
Number of Staff
2010
Discipline
(e.g. Managerial,
Technical, Sales etc)
Numbers employed
1-5 years experience
> 5 years experience
*Please provide details of LMS software development staff at section
8.13.2.4.*
7.1.5 Company Overview and Portfolio
Please attach a brief description of the company together with an overview of the product portfolio, current market focus and strategic direction.
Draft 9.2: Page 13 of 94

7.1.5 A company overview is attached
Yes No
7.1.6 Financial Profile and Accounts
Please attach a financial profile for the last three financial years with independently audited certified accounts.
7.1.6 Financial profile and audited accounts attached
Yes No
7.1.7 Insurance
Please attach details of Employer’s Liability; Public Liability, and
Professional Indemnity insurance.
7.1.7 Insurance details attached
7.1.8 References for previous projects
Yes No
For each of at least 3 similar contracts delivered successfully, please provide the following:
Reference 1
Client Organisation
Description of the contract
Precise services provided
Date of contract delivery
Value of the contract
Name of Client Contact
Position held by contact
Email address of contact
Address
Telephone number
Draft 9.2: Page 14 of 94

Client Organisation
Description of the contract
Precise services provided
Date of contract delivery
Value of the contract
Name of Client Contact
Position held by contact
Email address of contact
Address
Telephone number
Reference 2
Draft 9.2: Page 15 of 94

Reference 3
Client Organisation
Description of the contract
Precise services provided
Date of contract delivery
Value of the contract
Name of Client Contact
Position held by contact
Email address of contact
Address
Telephone number
LGMA and its agents may at their discretion visit reference sites without the presence of the tenderer.
7.2 Project Implementation and Management
7.2.1 Details of Staff assigned to this project
Tenderers must provide details of the implementation team proposed for this project: a) Project Implementation Team
Employee
Name
Proposed Role on
Project
1.
2.
3. b) Support Team
Number of years in
Organisation
Level in
Organisation
Employee
Name
1.
Proposed Role on
Project
Number of years in
Organisation
Level in
Organisation
Draft 9.2: Page 16 of 94

2.
3. c) Project Training Team
Employee
Name
1.
2.
3.
Proposed Role on
Project
Number of years in
Organisation
Level in
Organisation
Please expand these tables as required and please provide full CVs for all key staff involved in the project.
7.2.2 Project Management and Operating Plan
The LGMA requires that the project is managed in accordance with industry standard project management techniques.
The following structure is a suggested approach:
Project Sponsor - Senior Management representative from the Local
Authority
Project Board - Senior Management representative from the Local
Authority & Supplier
Local Authority Project Manager - I.S. or Library
Supplier Project Manager - Provided from Supplier Resources
Business Lead - Lead Representative from Local Authority Library
Project Team - Full/Part Time members Local Authority Library
Although each Local Authority Library will provide an individual
Project Manager, both the Local Authority Library and the supplier should work to an agreed single plan.
Tenderers should attach a project plan, including, but not limited to, details of: project timeline and milestones (see below); proposed governance structure; project organisation chart; training plan; risks management; key roles; contract mobilisation; technical resources; dedicated contract manager; contract monitoring; contract review meetings; contract administration, and billing procedures.
Draft 9.2: Page 17 of 94

7.2.2 A project plan is attached
Yes No
7.2.3 Project Timeline
The project plan (see above) should include a detailed project timeline with milestones and implementation target dates.
7.2.4 Training
The project plan (see 7.2.2) should include a training plan as set out in section 14 of the functional requirements).
7.2.5 Technical support
Tenderers must supply details in regard to the technical support service included in the price of the solution as per section 13 of the functional requirements.
Tenderers should note that the Irish library services generally operate on a Monday to Thursday 9am to 8pm basis, and on Friday and Saturday on a 9 to 5 basis, and during this core time would expect as a basic minimum a 4 hour on-site response time for component or network failure.
7.3 Pricing
The LGMA intends that all library authorities will use the single national system, beginning with the four Dublin authorities and Kildare County
Council (serving approximately 35% of the population). The remaining library authorities will join the service on a phased basis, over two years 3 .
Please specify your price in the matrix below, providing a price for the total population (4,588,252), and for varying percentages of the population, under the headings below. Prices should be on the basis of a five-year contract.
A.
Annual Subscription/Licence.
3 The actual timing of the implementation will be agreed with the successful tenderer.
Draft 9.2: Page 18 of 94

B.
Annual Maintenance Fee – If the annual maintenance fee is included in A please enter 0 (zero), otherwise enter the annual cost.
C.
Hosting – If an annual hosting fee is included in A or B please enter 0 (zero), otherwise enter the annual cost.
D.
Once-off implementation fee (including data migration).
E.
Bibliographic Records – If the supply of bibliographic records and enhanced Records is included in the annual subscription at A please enter 0 (zero), otherwise enter the annual cost.
F.
Annual licences for use of third party interconnectors - If licenses for third-party interconnectors are included in the annual subscription at A please enter 0 (zero), otherwise enter the annual cost.
All prices must be quoted in € (euro) and exclusive of VAT and any additional costs should be included separately.
Price matrix table % population served
100% 4 75% 50% 35%
A. Annual subscription/licence
B. Maintenance (if separate)
C. Hosting (if separate)
D. Implementation and training
E. Annual supply of bibliographic
and other records
F. Annual licences for use of third
party interconnectors
[enter name of interconnector]
[enter name of interconnector]
[enter name of interconnector]
G. Any additional costs required to deliver the project
H. Total Cost
(Add rows as required.)
4 The total population as recorded in the 2011 Census is 4,588,252.
Draft 9.2: Page 19 of 94

Optional Items
Please provide a cost for any optional items not included in the above.
7.3.2 Training
Please provide costs (daily rate) for training and consultancy which may be required in addition to that provided for in the implementation/annual subscription price.
Training
Consultancy
Daily rate (€)
7.4 Declarations
Tenderers must complete the declarations at appendices A1; A2; B; C, and D.
Draft 9.2: Page 20 of 94

Detailed functional requirements and specification are set out below, under the following headings:
8
9
10
11
12
13
14
15
4
5
6
7
1
2
3
General Requirements
Acquisitions and title/item management
Circulation/Reader Services - Staff Mediated
Serials (tracking magazine and newspaper holdings)
Resource discovery public user interfaces
Management Information and Reports
Database Management/Hosting (Cloud etc.)
Document delivery and inter-library loans
Fallback, Backup and Disaster Recovery
Security
Data Migration
Open standards, data, architecture & development strategy
Support, Product Lifecycle, Enhancements, Roadmap, SLA
Training
Consortium Working
The importance of each requirement is indicated as follows:
Importance(I):
Mandatory
Desirable
3
2
Preferable 1
With the exception of sections 12 (partial), 13 and 14 tenderers should answer how their proposed solution meets each requirement as follow:
Responses(R):
Planned(P):
Deliver by
(B):
Fully meet requirement
Partially meet requirement
Does not meet requirement
Currently in development
Planned development (provide delivery date)
Not planned
State quarter and year (e.g. Q1 2014)
Answer:
A
B
C
I
P
N
Tenderers must give an answer to each and every requirement. If the tenderer’s proposed solution does not currently meet the requirement (response in column R) but the vendor plans to meet it at a future date (response in column P), that date must be entered in column B and will be regarded as a firm commitment by
Draft 9.2: Page 21 of 94

the vendor and evaluated accordingly. Where development work will be required indicative costs must be provided in the pricing schedule and cross referenced to the functional requirement concerned.
Draft 9.2: Page 22 of 94

I
8.1 General Requirements
1.1
1.2
1.1.1
1.1.2
1.1.3
1.1.4
1.1.5
1.1.6
1.1.7
1.1.8
1.1.8 1.1.8.1
1.1.8.2
1.1.8.3
1.1.8.4
1.1.8.5
1.1.8.6
The system should, at a minimum, offer the following functionality:
Acquisitions
Circulation control and fulfilment
Serials control
User access via a variety of interfaces
Management information (including statistical analysis)
Database management
Document delivery and inter-library loans
Additionally the system should, avoid any duplication of data entry provide audit trails for all staff actions update asset status automatically allow multi-site operation comply with all legal requirements relating to disability including the Irish Disability Act 2005: http://www.irishstatutebook.ie/pdf/2005/en.act.2005.0014.pdf comply with all legal requirements relating to privacy including the Irish Data Protection (Amendment) Act 2003: http://www.irishstatutebook.ie/pdf/2003/EN.ACT.2003.0006.pdf
1.1.8.7 comply with all legal requirements relating to web safety and accessibility.
Operation, performance and user interface
The system should:
1.2.1
1.2.2
1.2.1.1 be accessible by staff and clients via web, mobile devices and workstations
Any limitations in terms of web access speed or in terms of device operating systems or browsers should be clearly identified by suppliers. permit the interrogation of the database by staff wherever workflows require it
3
3
3
3
3
3
3
3
3
3
3
3
3
3
2
3
3
R P B Comments
Draft 9.2: Page 23 of 94

1.2.3
1.2.4
1.2.5
1.2.6
1.2.7
1.3 Help
1.3.1
1.3.2
1.3.3
1.3.4
1.4 Documentation
1.4.1
1.4.1.1
1.4.1.2
1.4.1.3
1.4.1.4
1.5 Customisation and configuration
1.5.1
1.5.1.1
1.5.1.2
1.5.1.3
I provide audible as well as visual alerts where appropriate. display diacritic characters and a wide range of languages.
Suppliers to provide details of character sets and languages supported. provide shortcuts for frequently used operations use timeouts to terminate operations where appropriate operate with existing PCs, slip printers, scanners, and other devices. Suppliers to provide details of any exceptions.
Help facilities should, at a minimum, include:
Sample screens
Context-sensitive help
Search options for designated topics
Tutorials
Suppliers should give details of all documentation provided in each of the following areas:
User education
Staff training
System management
New software releases
The system should be customisable by the library to alter:
Data and formats displayed for all public user interfaces.
Suppliers to give details of any limitations
Data and formats displayed for all staff operations. Suppliers to give details of any limitations
Data and formats displayed for help screens. Suppliers to give details of any limitations
2
3
3
3
3
3
3
3
3
3
3
3
2
1
3
3
R P B Comments
Draft 9.2: Page 24 of 94

1.5.2
1.6 Access to the system
1.6.1
1.6.2
1.6.3
1.6.3.1
1.6.3.2
1.6.3.3
1.6.3.4
1.7 Communication Protocols
1.7.1
1.7.1.1
1.7.1.2
1.7.1.3
1.7.1.4
1.7.1.5
1.7.1.6
1.7.1.7
1.7.1.8
1.7.1.9
1.7.1.10
1.8 Integration and Interoperability
1.8.1
1.8.1.1
1.8.1.2
1.8.1.3
The design of the system configuration interface should be consistent with the rest of the system
I
3
R P B
Staff access to the system should be password protected
Access should be denied if a given number of attempts is exceeded
The system should provide: different access levels for different users the ability to prevent access to disallowed options the ability to restrict access to specific functions by groups of users and/or workstations easy maintenance of security access levels by specified staff
The solution provided should support:
TCP/IP
SIP version 2 (and version 3 when released)
ANSI/NISO z39.83 (NISO Circulation Interchange Protocol) and other industry data exchange standards where appropriate.
ISO 10160/10161
ODBC
Z39.50 / SRU/SRW
XML
FTP
HTTP
HTTPS
The system should facilitate integration with other systems where appropriate, including (but not limited to):
Financial Management Systems (including Aggresso and Oracle)
Geographic Information Systems
Radio Frequency Identification Systems
3
2
3
3
2
3
3
3
2
3
2
3
2
2
2
2
3
3
3
Comments
Draft 9.2: Page 25 of 94

I
1.8.1.4
1.8.1.5
1.8.1.6
1.8.1.7
1.8.1.8
1.8.1.9
1.8.1.10
1.8.1.11
8.2 Acquisitions and title item management
Resource discovery applications
Wi-Fi access
Print management
Access Control Systems
Social Media applications
Smartphone and smartcard applications
Credit Card transactions
Automated telephone renewal systems
2.1 General
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.1.8
2.1.9
2.1.10
2.2 Selection and ordering
The system should permit the acquisition of book, non-book, multimedia and digital assets
All acquisition functions should be fully integrated.
Audit trails should be maintained for all assets at all stages of the process
The system provider should support all EDI formats and messages used in the library supply chain. Suppliers should provide details of message sets supported.
The system should be certified as being EDI compliant by BIC's e4libraries programme
The format and content of acquisitions notices should be fully library-definable
The system should allow for input to be corrected and amended at all stages, including ‘undo’ operations
It should be possible to display 'on order' records to library clients and to selectively allow/disallow reservations to be placed
It should be possible to read barcodes and/or RFID tags in assets to aid acquisitions processing
The system should support the import of order/bibliographic data from suppliers and other record supply agencies
3
2
3
3
2
2
3
3
3
3
3
3
2
3
3
3
3
3
R P B Comments
Draft 9.2: Page 26 of 94

2.2.1
2.2.2
2.2.1.1
2.2.1.2
2.2.1.3
2.2.1.4
2.2.1.5
2.2.1.6
2.2.3
2.2.4
2.2.5
2.2.6
2.2.7
2.2.5.1
2.2.5.2
2.2.5.3
I
The system should support the following purchasing workflows:
Hard copy approval
Hard copy firm order
Hard copy continuation
Electronic firm order (package or single-title)
Electronic subscription (package or single-title)
User (Patron) or demand driven acquisitions (PDA/DDA) for both hard copy and electronic resources including:
2.2.1.6.1 creating and deleting candidate records for user discovery
2.2.1.6.2 creating purchase orders for purchased items
2.2.1.6.3 managing invoices for purchased items
2.2.1.6.4 creating local inventory for purchased items.
Supplier notifications under consideration may optionally be exported to the discovery environment to support user-driven collection development processes.
Approved selection items should generate orders that have the potential to be automatically ordered if they pass library-defined criteria (e.g. selector role, price and completeness of order line).
Library-defined criteria (such as incomplete order lines or prices above a threshold) should flag purchases for staff review
The system should support the prioritisation of purchase requests for or from users, by: limiting which users may place requests allowing staff mediation in the approval/rejection of purchase requests automating the ordering of requested purchases based on library-defined rules (i.e., user role, price)
The system should alert staff to outstanding reservations when a report is received
The system should notify and deliver requested items to users once received.
3
3
3
3
3
2
2
2
2
2
3
3
2
3
3
3
2
R P B Comments
Draft 9.2: Page 27 of 94

2.2.8
2.2.9
2.2.9.1
2.2.9.2
2.2.10
2.2.9.3
2.2.9.4
2.2.11
2.2.11.1
2.2.12
2.2.11.2
2.2.11.3
2.2.11.4
2.2.13
2.2.14
2.2.15
2.2.15.1
2.2.15.2
2.2.15.3
2.2.15.4
2.2.15.5
2.2.15.6
I
The system should support the setting up of evaluations of new e-resources before purchasing, to include managing participant feedback and groups of participants.
The system should also support the ability to evaluate existing electronic resource subscriptions and make recommendations for renewal or cancellation based on:
Usage levels
Cost
Changes in licensing arrangements
Changes in package contents.
The system should support the setting up of RSS feeds for newly acquired items.
The system should, allow session defaults to be set when creating orders, e.g. default supplier, fund, currency, location allow session defaults to be defined by location allow selected order data to be carried forward for a succession of records allow existing order records to be copied to form new orders e.g. for ordering additional copies
It should be possible to process multi-part or standing orders where multiple parts for a single order need to be receipted, invoiced and catalogued separately
It should be possible to process donations
It should be possible to process exchanges
Order records should be accessible by: bibliographic data elements order number order date supplier details status type
2
3
3
2
2
1
3
3
3
3
3
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 28 of 94

2.2.16
2.2.17
2.2.16.1
2.2.16.2
2.2.16.3
2.2.16.4
2.2.16.5
2.2.18
2.2.19
2.2.20
2.2.21
2.3 Receiving/Accessions
2.3.1
2.3.2
2.3.3
2.3.2.1
2.3.2.2
2.3.2.3
2.3.2.4
2.3.4
I
It should be possible to access the following data/functions directly from the order record (where applicable): full bibliographic record accession screen invoicing procedure and payment details prediction pattern supplier record
The system should allow for multiple copies of all types of items including subscriptions to be ordered for different locations and from different funds
It should be possible to flag subscription orders either to renew automatically or to alert staff before manual renewal is due
It should be possible to block automatic renewal if no parts have been received for any order and/or no payment has been made for purchase orders and to provide a report/message to supplier on such blocked records.
Once orders have been placed, funds should be committed immediately. Any subsequent amendment to price information should automatically update commitments
The system should facilitate consortium based purchasing
The system should allow hard copy items to be received from both approved purchase orders and invoices.
The system should allow for the receipt of the following item types:
Single-title monographs
Serial monographs
Issues of serials.
Other media e.g. DVD, CD
The system should be able to automatically create new item records when an item is received.
The system should notify staff when a volume or issue of a series has not arrived after a predefined interval, and allow for claiming
3
3
3
2
3
3
2
3
3
3
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 29 of 94

2.3.5
2.3.6
2.3.7
2.3.8
2.4 Activation
2.4.1
2.4.2
2.4.3
2.4.4
2.5 Supplier data
2.5.1
2.5.2
2.5.3
2.6 Invoice processing
2.6.1
2.6.2
2.6.2.1
I of missed items.
It should be possible to record the receipt of items for which there is no order.
The system should identify routing for received items based on the completeness of their metadata and item information (i.e. to cataloguing, physical processing, branch or shelf).
The system should be able to read RFID tags, where used, to facilitate automatic update of all financial and holdings records
The system should support the delivery of shelf-ready stock
The system should allow for the activation of approved purchases for electronic packages and titles.
The system should notify staff when an electronic package or title is activated.
When an electronic package or title is activated, descriptive records to describe the title(s) should be added to the catalogue automatically.
The system should indicate if there is a need to import/export data in order to support the e-resources lifecycle.
The system should provide the ability to maintain accounts for a single supplier.
The system should provide the ability to maintain multiple physical and email addresses for a single supplier, with the potential to tie these addresses to individual accounts.
The system should offer the ability to maintain discount and delivery information in the supplier record.
It should be possible to process invoices before receipt, at the time of receipt or at a later date
The system should be able to process: credit notes
3
2
2
2
2
2
2
2
3
3
3
3
3
R P B Comments
Draft 9.2: Page 30 of 94

2.6.3.2
2.6.3.3
2.6.3.4
2.6.3.5
2.6.3.6
2.6.3.7
2.6.3.8
2.6.3.9
2.6.2.2
2.6.2.3
2.6.2.4
2.6.2.5
2.6.2.6
2.6.2.7
2.6.3.1
2.6.3.10
2.6.3.11
2.6.6.1
2.6.6.2
2.6.6.3
2.6.6.4
2.6.3
2.6.4
2.6.5
2.6.6
2.6.7
I pro-forma invoices subscription invoices discounts on approval payments fund transfers handling charges
Invoice records should include the following elements: supplier details invoice number purchase order number invoice date invoice total discount amount delivery/postage and packing charges
VAT servicing charges (lamination, labelling etc.) link to orders covered by invoice free text note field
The system should allow online display of invoice data for a library-defined period
Invoice processing should reconcile invoice totals and individual amounts charged on invoices with line items
3
The system should provide an alert before accepting invoice data for the following: items which have been cancelled
The system should support the ability to automatically create a system invoice from a purchase order.
3 items which have claims outstanding 3 items which are charged to over-committed and overspent funds 2 items for which no parts have been received 3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 31 of 94

2.6.8
2.7 Fund accounting
2.7.1
2.7.2
2.7.3
2.7.4
2.7.5
2.7.6
2.7.7
2.7.8
2.7.9
2.7.10
2.8 Claiming and cancellations
The system should:
2.8.1
The system should support the export of payment requests to
ERP systems, as well as the import of payment confirmation files.
I
3
R P B
The system should support real-time access to fund balances
(including encumbrances and expenditures).
The system should support a hierarchical fund structure that provides the ability to group and report on funds.
The system should support optional fiscal year close processing.
For each fund, the system should provide links to invoices committed against that fund.
The system should support updated encumbrance estimations for foreign currencies based on daily conversion rates for foreign currencies stored as a central service.
Each fund should have the facility for library-defined limits on commitment and expenditure and warnings should be generated when these are reached
The system should maintain a currency exchange table which can be updated automatically; changes to the currency exchange table should automatically update commitments
The system should provide procedures for dealing with closing funds at the end of the financial year. It should be possible to roll over commitments to next financial year
For serial subscription renewals, the system should carry forward commitment based on the actual total cost of that subscription for the previous financial year
It should be possible to compare fund records for a librarydefined number of previous financial years allow a library-defined default claim period for each supplier
3
2
3
3
2
3
2
3
3
2
3
Comments
Draft 9.2: Page 32 of 94

I
2.8.2
2.8.3
2.8.4
2.8.5
2.8.6
2.8.7
2.8.8
2.8.9
2.9 Digital Deposit
2.9.1
2.9.1.1
2.9.1.2
2.9.1.3 allow for the default claim period to be amended on individual orders. Amendment of the delivery date should automatically reset the claims cycle permit claims by print, email and fax allow staff to force or suppress claims for individual items and subscriptions allow staff to either review items flagged for claiming before claims are generated, or generate claims without prior review allow authorised staff to cancel an order allow authorised staff to transfer an order to another supplier allow commitment details to be adjusted immediately upon cancellation of an order notify users who have requested/recommended an item if the order is cancelled
The product should support pre-defined workflows for upload of digitized material and their metadata including:
Automatic loading from pre-defined data sources (e.g. FTP) or
Manual via wizard (PC)
Defined automatic validation/enrichment during load
Optional sampling rates/approval process and dedicated interfaces for handling exceptions
8.3 Circulation/Reader Services - Staff Mediated
3
3
3
3
3
3
3
3
2
2
2
3.1 General
3.1.1
3.1.2
3.1.3
The system should have the capacity to manage all types of library material e.g. books, serials, electronic resources, digital materials, etc.
The system should be able to support variations in loan policy from site to site and authority to authority.
The system should be able to support lending policies based on customer demand, e.g. dynamic reassignment of loan periods.
3
3
3
R P B Comments
Draft 9.2: Page 33 of 94

3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
3.1.9
3.1.10
3.2
3.1.11
Common circulation functions
3.2.1
3.2.2
3.2.3
3.2.1.1
3.2.1.2
3.2.1.3
3.2.1.4
3.2.4
3.2.5
I
The system should allow authorised staff to modify all parameters relating to stock rotation/circulation with immediate effect.
The system should support the creation of circulation parameters common to multiple libraries.
The system should be fully compatible with self-service equipment including self-issue/return and book sorter machines.
The system should provide integration with third-party ILL systems using standard protocols.
The system should provide flexible policies to control access to digital material.
The system should allow the creation of library-defined grace periods
The system should maintain a calendar of closed dates for each location. All circulation transactions including due dates, fines, recalls and reservations awaiting collection should take account of closed days
Circulation should be able to operate with full functionality over
Citrix/VPN
The system should provide automatic blocks/alerts on borrowers, including for: expired ticket outstanding fines/fees (library-definable threshold) overdue/recalled items (library-defined threshold) borrowing over entitlement
Automatic blocks/alerts should be automatically removed
The system should allow authorised staff to input manual blocks with an explanatory message
Authorised staff should be able to override any borrower or item block.
The system should show the status of items (e.g. reserved, awaiting collection) at all times to both staff and end users
3
2
3
3
3
3
3
3
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 34 of 94

3.2.6
3.2.7
3.3
3.2.8
3.2.9
3.2.10
I
The system should maintain a loan history for both items and borrowers, retrievable for a library-defined period
The system should allow the circulation of un-catalogued items by recording brief information at the point of issue, using librarydefined defaults for loan control. Items should be automatically trapped on return to allow full details to be added.
The system should allow for loans of multiple sets, e.g. music, drama sets
3
2
3
The system should allow users to borrow, return and renew items at any service point within individual authorities.
The system should alert operators to return items to their
‘home’ location and manage the transit of such items, showing their current status at all times
The system should display a 'last use' column to help identify little used or lost items
It should be possible to enter the unique item identifier via barcode reader, RFID scanner or manual input
No borrower data should be required for return
Borrower and item status should be automatically checked on all three functions; any blocks/ accompanying messages should be displayed with an audible warning
It should be possible to override the calculated due date at the point of issue/renewal, subject to borrower and item checks
Borrower expiry date should override due date; warning of imminent expiry date should be given on screen
The system should provide a mechanism to terminate each transaction to prevent the issue of items to the wrong borrower.
It should be possible to backdate return dates for items deposited in book drops.
3
3
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 35 of 94

3.3.8
3.3.9
3.3.10
3.3.11
3.3.12
3.3.13
3.3.13.1
3.3.13.2
3.3.13.3
3.3.13.4
3.3.13.5
3.3.13.6
3.3.13.7
Fines and charges 3.4
I
The system should permit a status of ‘claimed returned’ to be added to an item allowing it to remain associated with the borrower whilst suppressing notices and fines.
The system should permit a status of ‘lost’ to be added to an item allowing it to remain associated with the borrower whilst suppressing notices and fines.
The system should alert staff if a ‘lost’ item is issued or returned.
3
3
3
It should be possible to flag items as ‘damaged’ and advise staff and borrowers on issue and return
It should be possible to flag items as comprising multiple elements, e.g. triple CD packs, and alert staff/users on issue and return to ensure sets are complete
The system should: allow the bulk renewal of all or selected items on loan (subject to borrower and item checks). prevent the renewal of overdue (library-defined threshold), reserved or recalled items, and items over the renewal limit print receipts for items issued, returned or renewed. allow renewal of items still on loan from the 'return' screen.
Linking to the borrower’s account should be direct, not requiring a borrower card or a borrower search. allow for renewal of unseen items via:
3.3.13.5.1 telephone (manual and automatic)
3.3.13.5.2 self-service device or via the public user interface provide direct access to the borrower record for personal, loans, fines and reservations details, from issue, return or renewal functions provide direct access to the full item record, including reservation information, from the borrower's loan record
3
3
3
3
3
2
3
3
3
3
R P B Comments
Draft 9.2: Page 36 of 94

3.4.1
3.4.2
3.4.2.1
3.4.2.2
3.4.2.3
3.4.3
3.4.4
3.4.5
3.4.2.4
3.4.2.5
3.4.2.6
3.4.2.7
3.4.2.8
3.4.6
3.4.7
3.4.8
3.4.9
3.4.9.1
3.4.9.2
3.4.9.3
3.4.9.4
I
The system should support the assessment of fines and fees for items, based on transaction policies defined by the library. This includes both overdue fines and lost item fees, which may be automatically applied after an item is overdue for a librarydefined period of time.
The system should: show full details for each fine or charge accumulate fines and charges for payment in a single transaction allow for payment to be accepted either in the Return function or by direct access to the fine payment screen from the Return function allow payment in full or part against any individual charge allow payment in full or part against all charges allow authorised staff to waive all or some fines/charges owing.
The reason for the waiver should be recorded.
It should be possible to defer payment (at the discretion of the library)
It should be possible to record the payment method
The system should enable group payment of fines, e.g. families
It should be possible to issue receipts of fines/charges paid.
The system should include cash management functions to enable reconciliation of income received by the system with amounts recorded on tills.
It should be possible to set a default replacement cost (where cost not specified on item record) for lost books
It should be possible to set processing/administration fees
Financial history should be retrievable for a library-defined period
It should be possible to handle other charges, including: subscription/membership charges hire charges reservation charges library sales
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 37 of 94

3.5
I
3.4.10 Financial transactions should be capable of being recorded to the authority financial systems.
3.4.11 The system should allow refunds to be made and recorded
Reservations, request management and smart fulfilment
3.5.1
3.5.2
3.5.3
The system should support business rules that automatically manage users’ requests allowing staff user mediation only when necessary.
The system should provide smart fulfilment, using a combination of user and item attributes to determine the best fulfilment method.
The system should support fulfilment of purchase requests submitted by borrowers via the resource discovery interface.
3.5.4
3.5.5
The system should support the fulfilment of requests via eBooks/eAudiobooks, streaming or link resolution to appropriate electronic resources.
The system should automatically generate notices to users when requested items are available. This notice may be in the form of an email or an SMS and should be generated in real time.
3.5.6
3.5.7
3.5.8
3.5.8.1
3.5.8.2
3.5.8.3
3.5.8.4
3.5.8.5
The system should support the administration of access rights for digital materials.
The system should support the administration of access rights for online services, including the ability to restrict access by IP address and federated access management where appropriate.
The system should: allow for maximum flexibility in determining loan policies.
Requirements currently vary considerably from authority to authority so suppliers are requested to give full details of options available. allow status monitoring of requested items. allow item category and copy specific reservations by staff only allow grouping of locations to satisfy reservations allow/disallow reservations on items on order
2
3
2
2
2
2
3
2
2
3
3
3
3
3
R P B Comments
Draft 9.2: Page 38 of 94

3.5.9
3.5.10
3.5.8.11
3.5.8.12
3.5.8.13
3.5.8.14
3.5.8.15
3.5.8.16
3.5.8.17
3.5.8.18
3.5.8.6
3.5.8.7
3.5.8.8
3.5.8.9
3.5.8.10 allow/disallow available items (i.e. on shelf) to be reserved if the reservation is placed in the library automatically notify staff at each site of reservations for items not on loan (remote reservations) for shelf checking. allow staff to record ‘not found’ status against remote reservation request allow for remote reservation requests to be routed between sites if copy is currently available at more than one site allow for a default collection point to be specified which can be changed if required by staff/end users allow the automatic or manual reduction of loan periods when there are outstanding reservations on items allow for the generation of recall notices and reduction of the loan period for reserved items (recall item due back soonest). alert staff when a reserved item is returned from loan and notify the requester that the item is awaiting collection alert staff/end users if a reservation is awaiting collection, whenever the borrower record is accessed allow for reservations to be cancelled automatically on expiration allow for reservations to be cancelled manually by staff (with provision for reason) allow for the creation of picking lists ordered by primary and secondary categories (e.g. Fiction, by Author) maintain a record of all of a borrower's previous loans - sortable by a variety of criteria including, but not limited to, author, date of publication, date borrowed
Authorised staff should be able to change the order of the reservation queue
It should be possible to set an expiry date for uncollected reservations, with automatic notification to staff (to remove from reserve shelf)
I
3
3
3
2
3
3
3
3
3
3
3
3
2
3
3
R P B Comments
Draft 9.2: Page 39 of 94

3.6
3.5.11
Borrower records
3.6.1
3.6.2
3.6.3
3.6.4
3.6.5
3.6.6
3.6.7
3.6.8
3.6.9
3.6.10
3.6.11
3.6.12
3.6.13
I
It should be possible to set an expiry date for unsatisfied reservations, with automatic notification to end users
Consistent with government public service computing strategy it should be possible to import, update and integrate borrower information from other sources including, but not limited to, other organisational databases, PPSN (Personal Public Service
Number) and GRO (General Register Office) data.
The system should be able to generate a PIN automatically or to accept an externally derived PIN.
It should be possible to create/edit borrower records manually in addition to importing them
It should be possible to duplicate data common to more than one borrower, e.g. family details
It should be possible to associate family member records - e.g. where parent stands as guarantor for child.
The system should provide the ability to create different user types and set circulation parameters for each type of user.
The system should provide an automatic change to borrower category based on age.
Borrower records should be capable of retrieval by name, membership number, address, and postcode.
Library staff should be able to delete borrower records, in bulk or individually, except where current transactions or blocks are outstanding
It should be possible to delete records by the date of expiry
New or replacement library cards should be attached to the existing borrower's details.
It should be possible to flag a borrower barcode/library card as
‘lost’, prohibiting transactions on that card and alerting staff if it is used
The system should be able both to generate unique user numbers and accept them from an externally derived source.
3
2
3
3
3
2
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 40 of 94

3.8
3.7
3.6.14
3.6.15
3.6.16
3.6.17
3.6.18
Bookings
3.7.1
3.8.3
3.8.4
Notices
3.8.1
3.8.2
3.8.1.1
3.8.1.2
3.8.1.3
3.8.1.4
3.8.1.5
3.8.2.1
3.8.2.2
3.8.2.3
3.8.2.4
3.8.2.5
I
The system should allow self-registration online.
Staff mediated registration should support predictive text - with alerts if duplicate membership of other libraries is detected.
Staff entry of PINs should be a secure process, suppliers are requested to provide full details of their system's capabilities in this area.
GIS data and forthcoming postcode identifier to be linked to borrower address information
Digital signature facility for certain user transactions may be required
The system should support asset loan management, e.g. PCs, either directly or via a third party system using industry standards where available
The system should support the automatic generation of notices, including: overdue letters fines replacement costs recalls notification of item awaiting collection
The system should support the transmission of notices via a range of formats including, but not limited to:
Print e-mail
SMS
Social media
Telephone
Text and format of notices should be library-defined
The system should handle failed SMS, email or social media notifications by automatically generating a print notice.
3
2
3
2
2
3
3
3
3
3
3
3
3
3
2
3
3
2
R P B Comments
Draft 9.2: Page 41 of 94

3.8.5
3.9
3.10
Short loans
3.9.1
3.9.2
3.9.3
3.9.4
3.9.3.1
3.9.3.2
3.9.3.3
3.9.3.4
3.9.3.5
3.9.3.6
3.9.3.7
Mobile library services
3.10.1
3.10.1.1
3.10.1.2
3.10.1.3
3.10.1.4
3.10.1.5
3.10.1.6
3.10.2
3.10.1.7
I
The system must be capable of flagging repeated failed texts/emails to the same phone number/email address. System to generate reports on an ongoing basis after two successive failed notices.
The system should allow for short loan periods to be set, including both hourly and overnight loans
Hourly loans should cater for both rolling hourly periods (e.g. items due back four hours after issue) and fixed times
It should be possible to set specific parameters for short loan items, to include:
2
2
2 loan periods loan entitlements renewal periods renewal limits
Reservations fine rates notice production
The system should support bookings of short loan items for a given date/time
The system should offer equivalent circulation functions to mobile libraries, to include: issue, return and renewal of items borrower loans and messages fines and charges interception of reserved items borrower registration borrower search resource discovery via public user interface
It should be possible to list all stop points and group them into routes
3
3
3
3
3
3
2
2
2
2
2
2
2
2
2
2
R P B Comments
Draft 9.2: Page 42 of 94

3.10.3
3.10.4
3.10.5
3.10.6
3.10.7
3.11
3.12
Housebound services
3.11.1
3.11.1.1
3.11.1.2
3.11.1.3
3.11.1.4
Stock rotation and routing
3.12.1
3.12.2
3.12.3
3.12.4
3.12.5
Loans should be associated with a stop point/route
The system should support bulk renewals of all loans at a stop point (for use if stop point is postponed)
Mobile library transactions should be synchronised with the main library system
Mobile circulation functions should permit the use of both diacritics and non-alphanumerics.
Mobile circulation software should be capable of being easily installed on replacement or rebuilt PCs.
I
3
3
R P B
3
3
3
Comments
The system should support services for the housebound including: creation of profiles and borrower history of housebound readers to enable selections to be made generation of picking lists issue and return of selected items to individual housebound readers according to specific parameters blocking issue and return of selected items to day centres, homes etc. according to specific parameters
It should be possible to move collections of stock from branch to branch on a rotating basis
The rota should incorporate dates for transfer of collections and produce an alert when collections are due to be moved
Items on loan in a collection should be routed to the new location
The system should support the generation of configurable routing slips
The system should alert staff if a copy of an item being added is a duplicate for that location.
3
3
3
3
3
2
2
2
3
Draft 9.2: Page 43 of 94

I
3.13
3.12.6
Back-up circulation
3.13.1
3.13.2
3.13.3
3.13.4
3.13.5
3.13.6
3.13.7
3.13.8
3.13.9
The system should maintain a history of item transfers between locations, retrievable for a library-defined period.
In the event of system or network failure, there should be a back-up circulation function capable of handling all issue and return transactions without disruption to services
Recovery of transactions should be possible as soon as the system is back online
Offline transactions should be processed in sequence to prevent errors.
Reservations outstanding on recovered offline return transactions should be reported.
Uploading of offline transactions should generate alerts in the same way as during online operation.
Remote locations with poor connectivity should be able to switch seamlessly between online and backup modes of operation
The back-up circulation function should be capable of uploading and processing transactions from multiple locations simultaneously.
Circulation backup software should be capable of being easily installed on replacement or rebuilt PCs.
Mobile circulation functions should permit the use of both diacritics and non-alphanumerics.
8.4 Serials (tracking magazine and newspaper holdings)
2
3
3
3
3
3
3
2
3
3
4.1 General
4.1.1
4.1.1.1
4.1.1.2
4.1.1.3
4.1.1.4
The system should provide for ongoing control of serial issues with regard to:
Check-in
Claiming
Routing
Binding
3
3
3
3
R P B Comments
Draft 9.2: Page 44 of 94

4.2
4.1.2
4.1.3
4.1.4
4.1.3.1
4.1.3.2
4.1.3.3
4.1.3.4
4.1.3.5
Check-in
4.2.1
4.2.2
4.2.1.1
4.2.1.2
4.2.1.3
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6
I
The system should allow for site-specific check-in, displaying only
‘home’ issues for check-in
It should be possible to access directly the following detail information attached to a serial title: receipt claims routing binding invoice
The system should display latest issue information via the resource discovery public user interface, updating serial holdings data automatically.
The system should allow access to serial records by the following:
Title
ISSN
Issue barcode
The system should: offer the option to show more than one expected/outstanding issue. Suppliers to give details of their capabilities in this regard. allow the creation of free-text notes at both title and issue level display these notes at point of check-in allow for check-in of non-standard issues, including:
4.2.2.4.1 supplements
4.2.2.4.2 special issues
4.2.2.4.3 parts received out of sequence
4.2.2.4.4 combined and double-numbered issues
4.2.2.4.5 duplicates
4.2.2.4.6 indexes allow staff to ‘un-receive’ an issue receipted in error alert staff to gaps in receipted issues at point of check-in
3
3
3
3
3
3
3
3
3
3
2
3
3
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 45 of 94

4.3 Prediction
4.3.1
4.3.1.1
4.3.1.2
4.3.1.3
4.3.1.4
4.3.1.5
4.3.1.6
4.3.1.7
4.3.1.8
4.3.1.9
4.3.1.10
4.3.1.11
4.3.1.12
4.3.1.13
4.4 Claiming
4.4.1
4.4.1.1
4.4.1.2
4.4.1.3
4.4.1.4
I
The system should: provide the facility to predict a wide range of publication patterns in terms of number of issues per week, per month, per year or over several years (biennial, triennial etc) allow patterns to support irregular but predictable publications such as combined issues, supplements and indexes handle irregular and unpredictable publications allow for changing the prediction pattern within a subscription year allow for stopping or suspending prediction for an individual title accommodate delays of any duration between nominal and actual date of publication support at least four levels of enumeration allow any combination of numeric, alphanumeric or date descriptors allow for volumes commencing at any time during the year allow for volumes covering more than one year allow for multiple volumes within a year allow for both continuous and restart issue numbering within volumes provide the option either to require a subscription renewal before parts are predicted for the next subscription period, or to allow subscriptions/predictions to roll over without manual intervention
The system should: generate claims based on predicted expected issue date together with library-defined claim period (by title or supplier) allow prior review of claims by staff generate claims for skipped issues automatically on receipt of subsequent issues permit claims by e-mail and fax.
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 46 of 94

I
4.6
4.5
4.4.2
Routing
4.5.1
4.5.2
4.4.1.5
4.5.1.1
4.5.1.2
4.5.1.3
4.5.1.4
4.5.1.5
Binding control
4.6.1
4.6.1.1 allow for supplier reports to be added to issues claimed; amendment of delivery date should reset the claims cycle
Claim formats and claim messages should be library-defined
The system should: allow the creation and maintenance of routing lists for specific copies of individual titles using the borrower file allow lists of titles/recipients to be edited on an individual or global basis alert staff to a routing list at check-in allow printing of routing lists at check-in, either on an individual basis or at the end of a check-in session alert staff to routed issues not returned
Format of routing slips should be library-defined
The system should: flag and identify items ready for binding according to librarydefined requirements
4.6.1.2
4.6.1.3
4.6.1.4 hold binder details and instructions record items at binding (issue, return, overdue) offer financial controls for binding
8.5 Resource discovery public user interfaces
5.1 General
5.1.1
3
3
3
3
3
3
3
3
3
3
3
3
The system should provide web-based, interactive, intuitive
"Google" type searching — including support for fuzzy logic, misspellings or variant spellings — across all library resources, whether physical or digital (e.g., images, audio and video files) and on different databases, using Web-Scale Discovery Services
(e.g. the VuFind open source library search engine). The interface should be user-friendly, and displays should be easily customised.
3
R P B Comments
Draft 9.2: Page 47 of 94

5.1.2
5.1.3
5.2
5.3
5.1.4
5.1.5
5.1.6
5.1.7
5.1.8
Indexing
5.2.1
5.2.2
5.2.1.1
5.2.1.2
5.2.2.1
Interfaces
5.2.2.2
5.3.1
5.3.1.1
5.3.1.2
I
The discovery layer should seamlessly integrate with library databases and external resources.
The system should be capable of acting as a gateway to all resources on offer in and through libraries: e.g. audio-visual formats, community information, networked electronic resources; and integrate links to externally held resources such as web sites
Users should be able to borrow ebooks via the online discovery layer
The system should support Z39.50 (current version) client and server
It should be possible to display help, including examples, on search screens
It should be possible to suppress certain categories of material from display to the public (e.g. no copies available for loan/request)
It should be possible to suppress individual bibliographic records from display to the public.
Suppliers are requested to provide full details of the indexing capabilities of their resource discovery offer with particular reference to: main indexes used optional indexes e.g. those based on MARC 02x tags and 03x tags (ISBNs, Music publisher nos., publisher catalogue nos., etc.)
The system should be able to sort the classification index for the following schemes, in accordance with general principles for the scheme:
Dewey (current edition)
Library of Congress (current edition)
The system should provide: integration with social media integration with smartphones/tablets
3
3
2
3
3
3
3
3
3
3
3
3
2
3
R P B Comments
Draft 9.2: Page 48 of 94

5.4
5.5
I
Searching
5.4.1
5.4.2
5.3.1.3
5.3.1.4
5.3.1.5
5.4.1.2
5.4.1.3
5.4.2.1
5.4.2.2
5.4.2.3
5.4.2.4 support for different languages including Irish the ability to personalise access to Web enabled services support for XML feeds for use in digital displays, widgets, etc.
Suppliers are requested to provide full details of the search capabilities of their resource discovery offer with particular reference to:
Searching techniques supported
Search filtering capabilities
The system should, as a minimum, provide: the capacity to order results of search by various criteria the ability to search for newest editions the ability to search for recently added stock the ability to display lists of newly acquired items broken down by collection or material type
5.4.2.5
5.4.2.6
5.5.1.5 the facility for users to compile and save their own reading lists. the ability to seamlessly search non-standard databases via a variety of means (e.g., newspaper/ journal index, Z39.50).
5.4.3
Display of search results and navigation
The system should support searching using variant spellings
5.5.1 The system should:
5.5.1.1
5.5.1.2
5.5.1.3 provide different levels of display and allow libraries to define which elements are included in each display (including full
MARC) allow the user to change the sort order allow users to view serial holdings, including serials check-in and latest issue information
5.5.1.4 support linking from bibliographic records to other electronic information resources both local and remote via URLs, URNs and other URIs indicate by the use of icons the format of an item (book, video, manuscript, journal article).
3
2
2
3
3
3
3
3
2
2
2
3
2
2
2
3
2
R P B Comments
Draft 9.2: Page 49 of 94

5.6
5.5.2
5.5.1.6
5.5.3
Outputs and personalisation
5.6.1
5.6.1.1
5.6.1.2
5.6.1.3
5.6.1.4
5.6.1.5
5.7 Self-service options
5.7.1
5.7.2
5.7.1.1
5.7.1.2
5.7.1.3
5.7.1.4
5.7.1.5
5.7.2.1
5.7.2.2
5.7.2.3
5.7.2.4
5.7.2.5
I display jacket cover images and other extended data
Search results should provide a list of previous searches made during the same session
Scans of fine bindings or title pages of early printed book should be stored and displayed for specified items
The system should: permit the creation of interactive and personalisable features such as book reviews, ratings, discussions threads and social tagging including linkage to Facebook, Google+, Twitter etc. allow users to mark or select references for printing and downloading allow users to review and edit the list and to sort items allow users to download, email or print lists of saved records. offer a range of output formats for exported records.
The system should allow users access to their own records and transaction details (as authorised by user ID/PIN). Transaction details should include: loans, including eBooks/eAudiobooks from external sources reservations within library-defined parameters, such as by collection, or by selected library. fines
ILL requests purchase requests
Users should be able to: make reservations cancel reservations make bookings for short loan material reserve library assets (e.g. PCs) remotely as determined by library policy. send print jobs to a print controller at staffed positions
3
2
1
2
2
2
2
3
3
3
3
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 50 of 94

I
5.7.3
5.7.4
5.7.5
5.7.2.6
5.7.2.7
5.7.2.8
5.7.2.9
5.7.2.10
5.7.2.11
5.8 SEO capabilities
5.8.1 make renewals make ILL requests and view progress make purchase requests update selected elements of their contact details change their PIN join online and to pay by credit card or through point-of-sale transaction system or other appropriate interfaces with the council's financial management system
The system should interface with automated telephone renewal systems.
The system should interface with self-issue/return devices using industry standards
The system should be able to restrict the total concurrent number of reservations made by borrowers through the discovery application.
Library catalogue database to be capable of being trawled by search-engine spiders/bots to ensure that library material is returned by searches run on the search engines
8.6 Management Information and Reports
3
3
3
3
3
2
2
3
3
2
6.1 General
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
The system should provide management information from the main functional areas (as listed in 6.3 - 6.7 below)
The solution should provide not only operational and usage report but analytics and preferably Business Intelligence (BI) capabilities.
The system should have the ability to access transaction data over a lengthy period to facilitate longitudinal analysis of data
The system should have the ability to schedule dataset retrieval.
The reporting & BI tool should support a variety of output options including, but not limited to, viewable online, send to printer, email and export to a spreadsheet.
3
2
2
2
3
R P B Comments
Draft 9.2: Page 51 of 94

6.1.6
6.1.7
6.1.8
6.1.9
6.1.10
6.1.11
6.1.12
6.1.13
6.1.14
6.1.15
6.1.16
6.1.17
6.1.18
It should be possible to save report specifications for re-use
The report interface should be intuitive, offering select and click functionality converting to graphs, charts and tables automatically
Outputs should be capable of being formatted and delivered according to library-defined parameters including reports to meet the requirements of Local Authority Service Indicators.
The system should offer the ability to allow easy retrieval of data for statutory returns and routine monitoring, and with options for user-friendly flexible customisation of ad hoc reports in a wide range of export formats including Public Library Authority
Statistics Actuals or LGMA equivalent.
A dashboard model with browser interface is preferred, featuring point and click to select, sort and generate outputs.
Library managers should be able to run simple ad hoc queries with minimal training.
Historical and snapshot query capacity is required across all functions.
Access to data should be controlled by library-defined parameters.
The reporting & BI system should support the ability to collaborate and share reports made by other parties.
The reporting and BI solution should allow layered reporting with drill down capabilities – for example: expenditure over year with drill down to quarters/items etc.
The reporting and BI system should be able to provide business intelligence capabilities and the analysis of different data gathered by the system to serve as a support for decision making process.
The reporting application should allow for the automatic scheduling of reports at defined intervals.
The reporting application should automatically update to take account of newly added (or removed) parameters.
I
3
2
R P B
3
3
2
3
2
3
2
2
1
2
2
Comments
Draft 9.2: Page 52 of 94

6.1.19
6.1.20
6.2 System Performance
6.2.1
6.2.2
6.3 Bibliographic database
6.3.1
6.3.1.1
6.3.1.2
6.3.1.3
6.3.1.4
6.3.1.5
6.3.1.6
6.3.1.7
6.3.1.8
6.3.2
6.4 Circulation
I
The system should provide details of all transactions made by users through the discovery interface including, but not limited to reservations, renewals, search terms used etc.
The system should be capable of incorporating other statistics relating to library activity.
The system should provide the ability to monitor, report and provide alerts on the performance of the system against agreed service levels.
Running any number of queries should not impact on performance of the LMS
3
1
3
3
R P B
The system should provide: statistics of records added to the database, broken down by library-defined categories, e.g. material type, class mark, type of record (local/external) lists of titles selected by a combination of a range of categories, e.g. date of input, class-mark / shelf-mark, material type bibliographic records with no items attached lists of new authority headings withdrawals inventory and stock check reports reports on overuse and underuse of stock by library-defined categories including, but not limited to: location, collection, broad classification, and author lists of titles selected by a combination of a range of categories, e.g. date of input, class-mark / shelf-mark, material type, location, price, unique identifier (e.g., barcode), invoice number.
Details of worn out or other items deleted from the database should be saved for up to seven years for statistical purposes.
3
3
3
3
3
2
2
3
1
Comments
Draft 9.2: Page 53 of 94

6.4.1
6.4.3.15
6.4.3.16
6.4.3.17
6.4.3.18
6.4.3.19
6.4.3.20
6.4.3.21
6.4.3.22
6.4.3.23
6.4.3.24
6.4.3.25
6.4.3.26
6.4.3.1
6.4.3.2
6.4.3.3
6.4.3.4
6.4.3.5
6.4.3.6
6.4.3.7
6.4.3.8
6.4.3.9
6.4.3.10
6.4.3.11
6.4.3.12
6.4.3.13
6.4.3.14
6.4.2
6.4.3
The system should provide a live view of current circulation activity - issues/discharges/renewals/reservations - by branch/service point
The system should collect, process and report PLR data in the required format.
Standard reports should include but not be limited to:
Registered Borrowers
Active Borrowers
Borrowers by library category, age, address etc
Borrower email address, mobile phone numbers
Lists of borrowers due to expire within library-defined period
Stock availability, by library & category, media etc
Stock last seen
Stock issues
Missing shelf checks
Stock rotation
Additions
Withdrawals, Stock transfers
Top ten listings
Lists of titles with specified loan status or collection category
Mobile library statistics, including breakdown by stop points
Issues
Daily, weekly, monthly transaction reports
Reserves outstanding, awaiting collection etc.
Cash Management
Session totals
Lodgements
Income
Sales by product
VAT charged
Fines and charges waived
Accounts
I
2
R P B Comments
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
2
3
3
3
3
3
3
3
Draft 9.2: Page 54 of 94

6.4.3.27
6.5 Acquisitions
6.5.1
6.5.1.1
6.5.1.2
6.5.1.3
6.5.1.4
6.5.1.5
6.5.1.6
6.5.1.7
6.5.1.8
6.5.1.9
6.5.1.10
6.5.1.11
6.5.1.12
6.5.1.13
6.5.1.14
6.5.1.15
6.6 Serials control
6.6.1
6.6.1.1
6.6.1.2
6.6.1.3
6.6.1.4
I
Fines Pending
The system should provide:
Acquisitions statistics by library-defined categories
Outstanding orders by supplier by fund, order date, order number, material type
Completed orders by supplier, fund, material type
All orders, by financial year; broken down by material type and supplier
Cancelled orders
User purchase requests
Lists of suppliers
Analysis of supplier performance e.g. average supply time, price and discount information, level of non-supply
Monthly, annual and on demand fund reports, including commitment and expenditure
Expenditure by supplier
Expenditure by library-defined subject areas
Lists of recent accessions
Statistics of EDI transactions
Budgets, by supplier, branch, category, media etc.
Items accessioned by library, category, supplier, media etc.
The system should provide:
Lists of titles with unfulfilled claims, after penultimate and final claims, by supplier
Cancelled subscriptions, by supplier / financial year
Cumulating daily, monthly and annual totals of issues checkedin, by library-defined categories, e.g. frequency, fund code
Lists of current serials by combinations of: title, classmark, supplier, material type, fund code
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
2
2
2
2
R P B Comments
Draft 9.2: Page 55 of 94

I
6.6.1.5
6.7 Inter-library loans
6.7.1
6.7.1.1
6.7.1.2
6.7.1.3
6.7.1.4
6.7.1.5
6.7.1.6
6.7.1.7
Number of volumes sent to bind, number returned, analysis of time spent at binding
The system should provide:
Statistics of ILL requests satisfied / unsatisfied / cancelled / outstanding
Statistics of items by supplier: requests satisfied / unsatisfied, by material type
Costs by supplier/fund/material type
Relative statistics of photocopies supplied / items for home loan
/ items issued for reference use
Supply times: average; shortest; longest
Statistics of items requested, broken down by borrower category and material type
Statistics of items supplied to other libraries: requests satisfied / unsatisfied, by material type
8.7 Database Management/Hosting (Cloud etc.)
2
3
3
3
2
3
3
3
7.1 General
7.1.1
7.1.2
7.1.3
7.1.4
The system should be hosted and managed and maintained with all necessary migrations and data updates to be carried out on behalf of the libraries by the supplier.
The solution should be cloud-based.
The system should support API and/or other interfaces to allow the client to develop extensions to the core software, as well as to integrate the software with the local institutional environment.
Documentation should be provided by the vendor as well as support for certifying any extensions developed by the library.
The vendor should also provide support for sharing of customerdeveloped extensions.
3
3
2
2
R P B Comments
Draft 9.2: Page 56 of 94

7.1.5
7.1.6
7.1.7
The system should offer robust interoperability with libraries' resource discovery platform. Such interoperability shall ensure that services developed for end-users that require resource management [i.e. user-driven acquisitions models] are available without additional integration work on the part of the library.
The system should be interoperable with third party databases and other applications e.g. Financial and Procurement systems,
Self Service systems, PC Booking systems, Evidence Based Stock
Management systems, Customer Relationship Management systems, WiFi Access Management systems etc. - LMS recommendation
The system should be ODBC compliant or alternative with secure and robust data transfer processes available
I
3
R P B
3
3
Comments
7.2 Format Support
7.2.1
7.2.2
7.2.3
7.2.4
7.2.5
The product should support shelf-ready acquisition and metadata provision; this will require full interoperability with established monograph and serials suppliers including, but not limited to, those currently delivering content as part of existing regional and/or national procurement frameworks.
Text in all records should support Unicode for importing, editing, storage and export.
The system should support import and export (with no loss of data) in all supported formats.
The system should support multiple metadata formats and be extensible to other formats. At a minimum, MARC21, Unicode,
Dublin Core and MODS should be available out-of-the-box. The metadata management environment should support functions appropriate to these formats.
The system must be compliant with ‘Resource Description and
Access’ (RDA) cataloguing rules.
3
3
3
3
3
Draft 9.2: Page 57 of 94

7.2.6
7.2.7
7.2.8
7.3 Record import and export
7.3.1
7.3.2
7.3.3
7.3.4
7.3.5
7.3.6
7.3.7
7.3.3.1
7.3.3.2
7.3.3.3
7.3.3.4
I
The system should support new fields and subfields added to
MARC to support RDA.
The system should support validation of appropriate use of elements, fields, subfields, and values, including validation of controlled vocabularies for fields (e.g. RDA content, carrier, and media terms).
The system should support Functional Requirements for
Bibliographic Records (FRBR)
The system should allow for the import of MARC records containing bibliographic and item information, and FRBR and
RDA data. The format of the item information and the data elements automatically uploaded should be determined by the library.
The library should be able to control the match and overlay rules to determine what happens records are loaded. These rules may differ when the file loaded contains item-level information in addition to bibliographic data.
When loading a record, or set of records, staff should have the following options for handling records detected as duplicate: add new records, ignoring duplicates not load new records when a duplicate is detected. merge the two records overwrite one record with the other
Authorised staff should be able to perform mass updates in an efficient, controlled way for all resources types (electronic/digital and print).
The system should allow for searching external databases through the online interface via z39.50 or SRU/W and importing resulting records to the catalogue.
The system should allow for the enhancement of incoming records according to library-defined bulk record change rules.
The system should allow for loading records singly or in bulk.
3
3
3
3
3
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 58 of 94

7.3.8
7.3.9
7.3.10
7.3.11
7.4 Record creation and editing
7.4.1
7.4.2
7.4.3
7.4.4
7.4.5
I
The system should allow for validation of incoming records according to library-defined validation rules.
The system should support the import of data via Z39.50,
SingleSource/ Bookstream.
The system should allow for the enhancement of exported records according to library-defined bulk record change rules, including the ability to enhance bibliographic records with holdings information.
The system should allow for the export of individual, groups of records, or an entire catalogue to a predefined target with no additional fee. Records to be exported may be based on a selected set, be an incremental set of records changed since the last export to the same target.
Cataloguers should be able to save drafts of records without committing them to the catalogue.
The system should have the same editing capabilities for all metadata types (physical, electronic and digital).
The system should highlight bibliographic records already on the database when the same control numbers (ISBN, ISSN) are entered, allowing an exact match among same editions of that title.
The system should provide a set of metadata management services that allows the library to easily and quickly define a set of records and perform actions against these records. For example, the library should be able to specify a group of records to be withdrawn from a collection or moved to an off-site storage facility; the library should be able, on import of metadata records from a specified source, to define a set of validation and normalisation routines to be applied to the records on import; similarly, the library should be able to define, on export of records, various data transposition routines, etc.
The system should support hotkeys for navigation and actions that allow editing entirely with the keyboard.
3
3
3
2
3
3
3
2
3
R P B Comments
Draft 9.2: Page 59 of 94

7.4.6
7.4.7
7.4.8
7.4.9
7.4.10
7.5.3
7.5.4
7.5 Authority control
7.5.1
7.5.2
7.6 Electronic resources
7.6.1
7.6.2
7.7 Item (copy) record management
I
The system should support record versioning, including the ability to view and roll back to past versions of that record.
The system should support the ability to edit all records through an online editor, including any element, field, subfield, or fixed field value as appropriate for the format.
The system should support the ability to perform changes in bulk against a set of records, including the ability to alter any element, field, subfield, or fixed field value.
The system should support the creation and storing of record templates for use in creating and editing records, including specifying default elements, fields, subfields, and values stored in these templates.
The system should support the display of cataloguing policies in the editor.
The system should allow libraries to create or load local authority files and records for subjects (including genre terms) and names.
The system should provide access to global, shared authority files without the need for individual libraries to synchronise with the authorising agency.
The system should support authorisation of bibliographic headings against local or global headings in authority records.
When a heading changes in a local or global authority record, the system should automatically make the change in bibliographic records that are authorised against that heading without staff intervention. The system should flag changes that request staff decisions, such as heading splits and newly qualified names.
The system should allow for the input of URLs, URNs, DOIs and other URIs in bibliographic records for electronic location and access information
The system should incorporate a link checker
2
3
3
3
2
2
2
3
2
3
3
R P B Comments
Draft 9.2: Page 60 of 94

7.7.1
7.7.2
7.7.3
7.7.4
7.7.5
7.7.6
7.8 Stock management
7.8.1
7.8.2
7.9 Shared Bibliographic Records
7.9.1
7.9.2
7.9.3
7.9.4
I
The system should allow unique item identifiers (e.g. barcodes,
RFID tags) to be assigned to item records on the system
There should be no effective limit to the number of item records linked to the bibliographic record
It should be possible to specify library-defined defaults for item data and to copy item data from one record to another
It should be possible to mark copies as withdrawn or deleted
The system should give a warning if the last copy is being withdrawn or deleted
It should be possible to assign a replacement item identifier to an item, and transfer all transaction data to the new item record
The system should support a stock checking facility, allowing the use of portable devices to store and upload item identifiers (e.g. barcodes, RFID tags) to the database, and report inconsistencies
The system should provide routines for bulk changes of data, e.g. location, loan category
Libraries should retain the right to remove their records from the shared catalogue. The supplier should not take ownership of the records or make any kind of charge for their use.
The system should provide access to a catalogue of bibliographic records shared by all libraries of that system. Libraries should be able to attach holdings directly to the shared records, edit the records, or copy them from the shared catalogue to the libraries’ local catalogue.
The system should support a local catalogue in addition to the shared catalogue for storing records that have local descriptive needs or terms of use that prevent their being shared with other libraries. Libraries should be able to use the shared catalogue, the local catalogue, or both simultaneously.
The system should support the addition of local fields to the shared records that are viewable only to the local library.
3
3
3
3
3
3
2
3
3
3
3
3
R P B Comments
Draft 9.2: Page 61 of 94

I
8.8 Document delivery and inter-library loans
8.1 General
8.1.1
8.1.2
8.1.3
8.1.4
8.1.5
8.1.6
8.1.1.1
8.1.1.2
8.1.1.3
8.2 Request process
8.2.1
8.2.1.1
8.2.1.2
8.2.1.3
8.2.1.4
8.2.1.5
8.2.1.6
8.2.1.7
Document delivery and inter-library loans should be integrated with the rest of the system, including: the resource discovery layer borrower records (to control ILL privileges) circulation control (for ongoing control of inter-library loans)
For requests input via the resource discovery public user interface (PUI), there should be facilities for staff to authorise and process requests
The system should support requests to other libraries
A file of supplying libraries should be maintained, accessible by code and library name
Format and content of notices should be library-definable
It should be possible to archive completed document delivery/ILL requests and make them available for access by staff for a library-defined period
The system should: check eligibility of borrowers to place requests allow a limit to be imposed on the number of concurrent requests from any user (by borrower category), with an overall limit over a library-defined period of time provide templates for entering the request (for monographs, serials, serial articles, conferences etc.) allow users entering requests via PUI to specify a collection point
(if applicable) allow requests to be created by uploading data from external databases allow library staff to amend the bibliographic and other request details before and after transmission of request allow for checking progress of requests via the PUI
3
3
3
3
3
2
3
1
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 62 of 94

8.2.2
8.2.3
8.2.4
8.2.5
8.2.6
8.3 Receipt and loan
8.3.1
8.3.2
8.3.3
8.3.3.1
8.2.1.8
8.2.1.9
8.2.1.10
8.2.2.1
8.2.2.2
8.2.2.3
8.3.3.2
8.3.3.3
I allow for special requirements to be added to requests, e.g. loan essential, translation only handle urgent requests, e.g. phone requests, and suppress transmission of the request concerned allow staff to access the request record in a number of ways, including:
8.2.1.10.1 bibliographic details
8.2.1.10.2 from the user record
The user record should display:
ILL items on loan outstanding requests progress reports
Requests should be displayed in chronological order with most recent first
Error detection should be provided and it should be possible to amend and retransmit files
It should be possible to change lenders for outstanding requests
It should be possible to initiate action to revive a cancelled request or to re-request a wrongly-supplied item
The system should record the receipt (with date) of requested items
It should be possible to amend the supplying library if different from the library from which the item was originally requested
The system should: allow a default due date to be set for each lending library
(library-defined) for loan items, and for ‘issuing’ items to be used in the library take account of closed days when calculating return dates notify the requester on receipt of an item, with details of collection point, due date, renewal conditions, and whether item is for use in the library only
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 63 of 94

I
8.4 Renewals
8.3.4
8.4.1
8.5.2
8.5.3
8.5.4
8.5.5
8.5.6
8.5.6.1
8.5.6.2
8.5.6.3
8.5.6.4
8.6 Loans to other libraries
8.6.1
8.6.2
8.4.1.1
8.4.1.2
8.5 Charges and funds
8.5.1
8.3.3.4 notify library staff if an item has not been collected within a library-defined period of time
Notifications should be possible via e-mail, print, SMS, social media and PUI
The system should: manage renewal of loans from other libraries produce printed or e-mail notices to renew with other libraries
It should be possible to handle charges imposed by document delivery providers
The system should support deposit and billing accounts
It should be possible to set up a number of accounting methods for one supplier
The system should allow funds to be set up for document delivery/ILL
Funds in ILL/document delivery should be linked to acquisitions funds
The system should maintain and display for each fund: fund allocation expenditure commitment cash balance
The system should provide a facility for loaning to other libraries
Control of loans (issue, renewal, recall, return, overdues) should use library-defined parameters.
8.9 Fallback, Backup and Disaster Recovery
9.1
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
9.1.1
Suppliers should provide details of their solution's capabilities in each of the following areas:
What functionality will be available for staff and users if the server is unreachable?
3
R P B Comments
Draft 9.2: Page 64 of 94

9.2
8.10 Security
10.1
10.2
9.1.2
9.1.3
10.3
10.4
10.5
10.6
10.6.1
10.6.2
10.6.3
10.6.4
10.7
10.6.5
10.8
10.9
I
What level of resilience is provided for cloud based applications?
What backup procedures (if any) will be required to maintain system operation?
Please give details of your disaster recovery procedures.
3
3
3
Solution to be provided should meet ISO/IEC 27001,
SAS70/SSAE16 standards
Solution to be provided should be compatible with PEPPOL (Pan-
European Public Procurement OnLine)
The LMS and associated databases and applications must employ demonstrated industry standard levels of security.
Access to staff and user accounts should be secure, and tenderers should provide details of the level of security employed.
Access to the system must be password protected: tenderers should provide details of how passwords are stored and what algorithm/encryption is used
The system should:
Prevent access once a pre-set number of login attempts is exceeded
Allow different levels of access to functions/sub-functions according to level of user
Suppress disallowed options
Restrict groups of users/workstations to specific functions
Permit maintenance of access levels by library staff
All systems must facilitate use of generic and unique logins for all users and administrators.
All applications must feature logging of security events such as failed logins or access to critical data.
All logs should include a date and timestamp and identify the source and type of event.
3
3
3
3
3
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 65 of 94

8.11 Data Migration
11.1
11.2
11.3
11.4
11.5
11.6
11.7
11.8
11.9
11.10
I
Suppliers will be required to assure the integrity of the data after upload and suppliers should provide a test plan formulated for this purpose. (Note: Test scripts will be run against the newly migrated data and the originating Library Service will subsequently confirm satisfactory migration based on a 10%
random sample.)
The system should support the transfer of data from UKMARC to
MARC21
The system should initially be tolerant of records that are not fully compliant with AACR2
Complete and accurate data migration is required without loss or corruption of data.
Suppliers should provide details of their suggested and preferred data migration approach.
Suppliers should detail their role in the data migration
Suppliers should specify the Library Services’ role in the data migration
Data to be migrated should include all borrower, title, item, loan transaction, account transaction, system parameters, reservation data, etc. Suppliers should provide details of any limitations to these requirements.
The successful supplier will be required to prepare data for migration. This process may entail data cleansing, restructuring and presenting it in a suitable format for migration prior to its upload to the new system. Suppliers should provide details of any limitations to these requirements.
Suppliers should describe their approach to local catalogue migration as the project will require the integration of catalogue data for many of the same titles from a number of sources.
3
3
2
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 66 of 94

I
11.11 Suppliers should detail alternative approaches to catalogue title development and enrichment to maximise library customer experience of the catalogue and benefits of the chosen LMS. The supplier should include cost structures for such an approach.
3
8.12 Open standards, data, architecture & development strategy
Some responses in this section will be marked under award criteria C.
12.1 Standards
12.1.1
12.1.2
Irish libraries are committed to the provision and use of Open data and standards wherever possible. Suppliers should demonstrate their commitment to these ideals by providing full details of their planned and existing use of open standards in all areas of their proposed solution and by providing a policy statement on making data 'open'.
The replacement library management system should be fully compliant will all aspects of Open Access. Suppliers should provide evidence of their commitment to these requirements.
12.1.3 The proposed solution should demonstrate how it manages technological changes to ensure compatibility with new standards and system architectures.
*
*
*
12.2 Data
12.2.1 "Open Data" refers to the publication of data in machine readable, non-proprietary formats for the purpose of reuse by others. This is in accordance with the principles of the Reuse of
Public Sector Information Directive[1] and Open Data related actions outlined in the eGovernment Action Plan[2]. An overriding principle is that the publication of Open Data must not breach Data Protection legislation. The library management system must include the ability to publish relevant Open Data.
Suppliers should provide details of any limitations to these requirements.
3
R P B Comments
Draft 9.2: Page 67 of 94

12.2.2
12.2.3
12.2.4
12.2.5
12.2.6
12.3 Architecture
12.3.1
12.3.2
12.3.3
I
Examples of datasets to be published as Open Data from the library management system would include (but are not limited to) the Library Catalogue, Membership (aggregated or anonymised), Library Visitors, Items Issued/Renewed, Bookings, etc. Suppliers should provide details of any limitations to these requirements.
Datasets should have associated metadata such as the Dublinked
Metadata Profile[3] which was developed by the Dublinked project. Suppliers should confirm their ability to meet this requirement.
Datasets must be made available in open formats such as CSV,
XML or JSON. Ideally the datasets should also be publishable in
Linked Data formats such as RDF. Suppliers should confirm their ability to meet this requirement.
The associated metadata must also be made available for publication in Open Data catalogues in open formats such as CSV or XML and also ideally for Linked Data Catalogues such as
DCAT[4]. Suppliers should confirm their ability to meet this requirement.
Datasets should be exportable as bulk downloads – preferably with the ability to automate and schedule such exports.
Suppliers should confirm their ability to meet this requirement.
The architecture should be consistent with Government cloud computing strategy. Suppliers should confirm their ability to meet this requirement.
The system should be Web-based and optimised for operation from devices with slower connections, e.g. VPN libraries, mobile libraries using 3G broadband connections. Suppliers should confirm their ability to meet this requirement.
The system must be robust in terms of connectivity. It should not be oversensitive to minor network drops and should be able to re-establish connection automatically once communication is restored, without the need for renewed login. Suppliers should confirm their ability to meet this requirement.
*
2
3
3
3
2
2
3
R P B Comments
Draft 9.2: Page 68 of 94

I R P B Comments
12.3.4 The library management system should support APIs – including a controlled API for interfaces with other Local Government systems and an open API for public access requests including applications and services. Suppliers should confirm their ability to meet this requirement.
12.3.4.1 The controlled API should enable access by trusted Local
Government applications such as ePayment systems. Suppliers should confirm their ability to meet this requirement.
12.3.4.2 The open API should provide access to relevant Open Data from the library management system (similar to the API for
FixYourStreet[5]). Provision must be made for addressing any potential performance issues that might arise with the library management system as a result of the use of the open API. Such provision could include limiting API requests or dynamic resource scaling to meet demand. Suppliers should confirm their ability to meet this requirement.
3
3
3
12.3.4.3 The open API should enable the development of third party applications and services. Suppliers should confirm their ability to meet this requirement.
References
[1] http://psi.gov.ie/ ; [2] http://egovstrategy.gov.ie/ensure-that-public-service-data-is-available-for-re-use/ ; [3]
3 http://www.dublinked.ie/datastore/local/Dublinked/catalog/Dublinked-Metadata-Profile-v1.1-draft.pdf
; [4] http://www.w3.org/TR/vocab-dcat/ ;
[5] http://www.fixyourstreet.ie/page/index/1
I R P B Comments
8.13 Support, Product Lifecycle, Enhancements, Roadmap, SLA
13.1 Support - responses in this section will be marked under award criteria B.
13.1.1
13.1.2
Suppliers must provide a detailed description of their options for ongoing support
Suppliers must specify their standard terms for the provision of support for:
*
Draft 9.2: Page 69 of 94

I R P B
13.1.3
13.1.4
13.1.2.1 Support and advice in the Administration and Operation of the system by library staff
13.1.2.2 Support and advice in the use of the system by the public
13.1.2.3 General Query support
13.1.2.4 Performance Issues
The successful supplier must:
13.1.3.1 Commit to agreed response times depending on defined call classifications
13.1.3.2 Provide examples of any call classification scheme they use for these types of solutions
Each library staff user must be able to view the status of their logged incidents and requests online.
*
*
*
*
*
*
*
13.1.5
13.1.6
13.1.7
Suppliers must provide details of their Problem Management process and provide details of their tracking and escalation procedures.
Suppliers should supply monthly statistical information relating to the company’s performance in relation to logged incidents.
The successful supplier should:
13.1.7.1 Provide a single point of contact to manage the account.
13.1.7.2 Meet as agreed on a regular basis to review performance against the SLA.
13.1.7.3 Provide a report on the environment and the service statistics including capacity, availability and performance.
*
*
*
*
*
13.1.8 Suppliers should provide details of any User Groups or client
Forums.
*
13.2 Product Lifecycle, Enhancements and Roadmap – responses in this section will be marked under award criteria C.
13.2.1 Suppliers should provide an outline of the product’s lifecycle and developmental history.
*
13.2.2 Suppliers should provide details of their procedures for managing requests for enhancements and whether these are included in the support arrangements.
*
Comments
Draft 9.2: Page 70 of 94

I
13.2.3
13.2.4
Suppliers should provide a roadmap outlining their projected development strategy for the next five years. The library authorities' legal representatives will be happy to sign a nondisclosure agreement (NDA) if required.
Suppliers should provide the following information relating to staff dedicated to library management system development:
-
Number of staff with less than five years experience
-
Number of staff with five or more years experience
13.3 Service Level Agreement – responses in this section will be marked under award criteria B.
13.3.1
13.3.2
Suppliers should provide a copy of their standard Service Level
Agreement (SLA)
Cloud- based solutions are proving a challenge for both suppliers and their clients in agreeing an SLA. The consortium understands that it will be necessary to negotiate with the successful supplier to reach agreement on acceptable levels of service, however suppliers should indicate their current position in regard to each of the following service elements:
13.3.2.1 Availability (e.g. 99.99% during work days, 99.9% for nights/weekends)
13.3.2.2 Performance (e.g. maximum response times)
*
*
*
*
*
13.3.2.3 Security / privacy of the data (e.g. encrypting all stored and transmitted data)
13.3.2.4 Disaster Recovery expectations (e.g. worse case recovery commitment)
13.3.2.5 Location of the data (e.g. consistent with local legislation)
*
*
*
13.3.2.6 Access to the data (e.g. data retrievable from provider in readable format)
13.3.2.7 Portability of the data (e.g. ability to move data to a different provider)
*
*
13.3.2.8 Process to identify problems and resolution expectations (e.g. call centre)
13.3.2.9 Change management process (e.g. changes – rollout of updates or new services)
*
*
13.3.2.10 Dispute mediation process (e.g. escalation process, *
R P B Comments
Draft 9.2: Page 71 of 94

I consequences)
13.3.2.11 Exit strategy with expectations on the provider to ensure smooth transition
8. 14 Training
Responses in this section will be marked under Award Criteria B.
Each Library Authority in the Consortium will develop a training plan as part of the Library
Management System implementation, the successful tenderer having a large input into the training plan.
The plan will identify:
The different user types (including basic users, system administrators, Council ICT support staff)
The numbers of different users
Specific training requirements in the areas of:
Technical Administration – how the system is managed in the context of the control of system access, system configuration and content management.
Content creation – describing the tools used for the creation and publishing of content
R P B
System use – the navigation through, and use of the system, in all modules, from the end user’s viewpoint (both staff and public).
14.1
The most appropriate timing for the training
Suppliers should specify how they will meet these requirements
14.2 Suppliers should provide details of what training is included as part of the overall proposal.
14.3
14.4
Suppliers should provide an indication of the cost (if any) of any additional training that may be required post-implementation to fulfil the above criteria.
Suppliers should provide details of the training and testing environment provided.
*
*
*
*
*
Comments
Draft 9.2: Page 72 of 94

8.15 Consortium Working
15.1 System Parameters
15.1.1
15.1.2
15.1.3
15.1.4
15.1.5
15.1.6
15.1.7
15.1.8
I
The LGMA seeks to implement a single shared system with a single shared database, with each member authority able to set its own parameters, individually or in-line with all or other of the members of the Consortium. Suppliers should explain how their solution meets this requirement together with details of any limitations.
Authorised library staff must be able to update parameters with immediate effect
Each library authority must be able individually, or in agreement with all or other members of the Consortium, to customise the staff and public-facing functionality and appearance of the system as required.
Authority controls should operate across all consortium member systems.
The system should alert staff when attempting to withdraw the consortium's last copy.
Current circulation policies differ from authority to authority.
Suppliers should provide details of their to implement different policies in a consortium context.
Searching should be possible on a single location, group of locations, or all locations. Suppliers should provide details of their solution's abilities in this regard.
Current classification schemes differ from authority to authority.
Suppliers should provide details of their ability to implement different schemes in a consortium context.
3
3
3
3
3
3
3
3
R P B Comments
Draft 9.2: Page 73 of 94

DECLARATION (as per Article 45 of Directive 2004/18/EC &
Regulation 53 S.I. 329 of 2006)
THIS DECLARATION, DULY COMPLETED AND SIGNED, MUST BE
SUBMITTED BY ALL CANDIDATES/TENDERERS
Name of Candidate:
Address:
Country:
Please tick Yes or No as appropriate to the following statements relating to the current status of your organisation.
Article 45 (1) (Any Tenderer shall be excluded from participation who has been convicted of an offence involving):
1.a) The Candidate, a Director or Partner has been convicted of being a member of a criminal organisation.
1.b) The Candidate, a Director or Partner has been found guilty of corruption.
Yes [ ] No [ ]
Yes [ ] No [ ]
1.c) The Candidate, a Director or Partner has been found guilty of fraud.
Yes [ ] No [ ]
1.d) The Candidate, a Director or Partner has been found guilty of money laundering.
Yes [ ] No [ ]
Draft 9.2: Page 74 of 94

Article 45 (2) (Any Tenderer may be excluded from participation, where):
2.a) The Candidate is bankrupt or is being wound up or its affairs are being administered by the court, or has entered into an arrangement with creditors or has suspended business activities or is in any analogous situation arising from a similar procedure under national laws and regulations.
2.b) The Candidate is the subject of proceedings for a declaration of bankruptcy, for an order for compulsory
Yes [ ] No [ ] winding up or administration by the court or for an arrangement with creditors or of any other similar proceedings under national laws and regulations.
2.c,d) The Candidate, a Director or Partner, has been convicted of an offence concerning his professional conduct by a judgement which has the force of res judicata or been guilty of grave professional misconduct in the course of their business.
2.e,f) The Candidate has not fulfilled its obligations relating to the payment of taxes or social security contributions in Ireland or any other State in which the
Candidate is located.
Yes [ ] No [ ]
Yes [ ] No [ ]
Yes [ ] No [ ]
2.g) The Candidate has been guilty of serious misrepresentation in providing information to a public buying agency.
In addition to the above, please declare:
The Candidate has contrived to misrepresent its Health
& Safety information Quality Assurance information or any other information relevant to this application.
Yes [ ] No [ ]
Yes [ ] No [ ]
Draft 9.2: Page 75 of 94

THIS FORM MUST BE COMPLETED AND SIGNED BY A DULY AUTHORISED
OFFICER OF THE CANDIDATE’S ORGANISATION
I certify that the information provided above is accurate and complete to the best of my knowledge and belief.
I understand that the provision of inaccurate or misleading information in this declaration may lead to my organisation being excluded from participation in future Tenders.
SIGNATURE:
[Signature must be that of a Director/Principal]
DATE:
NAME:
POSITION:
TEL:
FAX:
Draft 9.2: Page 76 of 94

Name of Tenderer:
Tax Clearance
I confirm and declare having a current and valid Tax Clearance Certificate in place and our tax affairs are in order.
The Contracting Authority can verify your tax clearance status through Revenue’s online facility at https://www.revenue.ie/itp/view.jsp
. To this end, please confirm:
Do you grant the Contracting Authority permission to verify your tax cleared position online?
Registration Number
(as shown in your Tax Clearance Certificate)
Please confirm
YES/NO
Certificate Number
(as shown in your Tax Clearance Certificate)
OR
I confirm that I have applied for a Tax Clearance Certificate which will be made available on request
Turnover and Profitability
I confirm that our turnover exceeded €2,000,000 in any of the last three financial years, or pro-rata if more recently established.
I confirm that I will provide evidence of turnover and other financial information promptly on request at any time prior to the award decision being made.
I confirm that the company was in profitability in the last year.
I confirm that I will submit details of level of profitability for the last three financial years on request at any time prior to the award decision being made.
Bank details
I confirm that the company holds a bank account and that we are currently in good standing with our bank.
I confirm that I will submit bank details (bank name and branch, and details of main contact) on request at any time prior to the award decision being made.
Insurances
I confirm that we have the following insurances in place:
Employers Liability - €13 million
Public Liability - €6.5 million
Professional Indemnity - €1 million
Product Liability - €6.5 million
OR
I confirm that if successful I will be in a position to put the required forms and levels of insurances required for the contract in place.
I confirm that I will provide the following promptly on request at any time prior to the award decision being made: evidence of insurances in place or letter from Insurance Broker confirming that the required levels could be put in
Draft 9.2: Page 77 of 94

place if successful
Declarations must be signed by a duly authorised officer.
I hereby declare that the above is an accurate and complete Declaration of Financial and
Economic Capacity on the part of my firm in relation to this Tender competition. I undertake to inform the Contracting Authority of any changes to this Declaration which may arise prior to the award of contract.
Signed :
Name :
Position :
Date :
Draft 9.2: Page 78 of 94

Tender Competition: Irish Public Libraries LMS Tender
Name of Tenderer:
Quality Assurance Systems
I confirm that the company has Quality Assurance System(s) in place.
I confirm that I will submit statement of Quality Assurance systems in place on
Please confirm
YES/NO request at any time prior to the award decision being made.
Health and Safety Systems
I confirm that the company has Health and Safety System(s) in place.
I confirm that I will submit statement of Health and Safety systems in place on request at any time prior to the award decision being made.
Business Continuity Plan
I confirm that the company has a Business Continuity Plan in place.
I confirm that the company Business Continuity Plan is tested on a regular basis
I confirm that I will submit statement of the Business Continuity Plan in place on request at any time prior to the award decision being made.
Declarations must be signed by a duly authorised officer.
I hereby declare that the above is an accurate and complete Declaration of Quality Assurance systems,
Health and Safety systems and Business Continuity Planning on the part of my firm in relation to this
Tender competition. I undertake to inform the Contracting Authority of any changes to this Declaration which may arise prior to the award of contract.
Signed :
Name :
Position :
Date :
Draft 9.2: Page 79 of 94

To:
From:
Tender for: A new Library Management System
We, _________________________________________, confirm that
We are fully compliant with the terms and conditions and our statutory obligations under all relevant Irish employment and Health & Safety legislation.
We have procedures in place to ensure that our subcontractors, if any are used for this contract, apply the same standards.
I certify that the information provided above is accurate and complete to the best of my knowledge and belief. I understand that the provision of inaccurate or misleading information in this declaration may lead to my organisation being excluded from participation in future tenders.
Signed:
Print Name:
Company
Name:
Address:
Position:
Phone
No:
Date:
Draft 9.2: Page 80 of 94

1. Sufficiency & Accuracy of Tender
Tenderers will be deemed to have examined all the documents issued as part of the invitation to tender and by their own independent observations and enquiries will be held to have fully informed themselves as to the nature and extent of the requirements of this tender.
Tenderers are advised to check the accuracy of their tender prior to submission. A tender found to contain any clerical errors or omissions may, at the sole discretion of LGMA, be referred back to the tenderer for correction.
Any subsequent adjustment(s) must be confirmed in writing. LGMA reserves the right to disqualify incomplete tenders.
2.Tender Documents - Ambiguity, Discrepancy, Error, Omission
If you consider that you are missing any documents which would prevent you from submitting a comprehensive tender please contact Jackie Russell at jrussell@lgma.ie
.
You should also inform LGMA of any ambiguity, discrepancy or error in the
Tender Documents. LGMA shall, upon receipt of such notification, notify all
Tenderers of its ruling in respect of any such ambiguity, discrepancy, error or omission. Such ruling shall be issued in writing and shall form part of the
Invitation to Tender.
3. Closing Date and Time for Receipt of Tenders
The deadline date for receipt of Tenders is Friday, 3 rd January 2014 @ 12 noon (Irish time).
4 Queries
All queries regarding this tender should be emailed to jrussell@lgma.ie
.
Queries must be in question format and must be submitted by email.
Responses will be circulated to those Tenderers that have registered an interest in this notice on the Irish Government Procurement Opportunities
Portal www.etenders.gov.ie
. The details of the person making a query will not be disclosed when circulating the response.
Draft 9.2: Page 81 of 94

All queries should be submitted before Friday 20 th December 2013 @ 12
noon to enable issue of responses to all interested parties.
5. Qualification of Tenders
Please note that qualifications to a Tender may be considered a counter offer and may render the tender invalid.
6. Tender Submissions
The completed Tender (four hard-copies plus one electronic copy) should be enclosed in a sealed envelope and submitted either by post or hand delivery using the following label as a template:
Tender Enclosed
Tender for Library Management System
Delivery to:
Secretary
L.G.M.A.
Local Government House
35-39 Ushers Quay
Dublin 8
The Tenderer is fully responsible for the safe and timely delivery of the
Tender.
Emailed, faxed or late tenders cannot be considered and will be returned.
7. Extension of Tender Period
LGMA reserves the right, at its sole discretion, to extend the closing date for receipt of tenders by giving notice in writing to Tenderers before the original closing date.
8. Modifications to Tenders prior to the Closing Date for Receipt of
Tenders
Modifications to Tenders will be accepted in the form of supplementary information and/or addenda, provided they are submitted in a sealed envelope before the closing date for receipt of tenders.
Draft 9.2: Page 82 of 94

Any modifications received after the closing time for receipt of tenders will be returned to the tenderer unopened.
9. Cost of Preparation of Tender
LGMA will not be liable for any costs incurred by tenderers in the preparation of proposals or any associated work effort. It is the responsibility of the tenderer to ensure that they are fully aware and understand the requirements as laid down in this document. Tenderers will be responsible for any costs incurred by them in the event of their being required to attend clarification or other meetings or make a presentation of their Tender.
10. Tender Validity Period
To allow sufficient time for Tender assessment a Tender Validity period of twelve months is required, this period commencing on the closing date by which the Tenders are to be returned.
11. Currency
Tender prices must be submitted in Euro only. All invoices and payments will be in Euro only.
12. Confidentiality
The distribution of the tender documents is for the sole purpose of obtaining offers. The distribution does not grant permission or licence to use the documents for any other purpose.
Tenderers are required to treat the details of all documents supplied in connection with the tender process as private and confidential.
13. Conflict of Interest
Any conflict of interest involving a tenderer (or tenderers in the event of a consortium bid) must be fully disclosed to LGMA. Any declarable interest involving the tenderer and employees of the members of the consortium or their relatives must be fully disclosed in the response to this tender competition. The term ‘declarable interest’ shall be interpreted as per section
175 of the Local Government Act, 2001. Failure to disclose a conflict of
Draft 9.2: Page 83 of 94

interest may disqualify a tenderer or invalidate an award of contract, depending on when the conflict of interest comes to light.
14. Freedom of Information Act
Each of the parties will undertake to use their reasonable endeavours to hold confidential any confidential information received from the other party, subject to LGMA’s obligations under law, including (if applicable) the provisions of the Freedom of Information Acts, 1997 and 2003. The Tenderer will agree that, should it wish any confidential information supplied by it to
LGMA not to be disclosed, because of its commercial sensitivity, it will, when supplying such information, identify same and specify the reasons for its sensitivity. LGMA will consult with the Tenderer about such sensitive information before making a decision regarding release of such information under the Freedom of Information Acts 1997 and 2003. However, LGMA will give no undertaking or assurance that such information will not be released under the provisions of the Freedom of Information Acts 1997 and 2003 and the final decision on whether or not to release such information rests with
LGMA or as set out in the Freedom of Information Acts 1997 and 2003.
15. Tax Clearance Certificate
It will be a condition for award of the contract that the successful tenderer(s) can promptly produce a current Tax Clearance Certificate as per the declaration at appendix B.
16. Irish Legislation
Tenderers should be aware that national legislation applies in matters such as
Employment, Working Hours, Official Secrets, Data Protection and Health and
Safety. All relevant aspects of such legislation must be observed at all times by the successful tenderer.
17. Confidentiality of Evaluation
After the official opening of Tenders, information relating to the examination, clarification, evaluation and comparison of Tenders and recommendations concerning the award of contract will not be disclosed to Tenderers or other persons not officially concerned with such process until the award of contract
Draft 9.2: Page 84 of 94

to the successful Tenderer has been announced and in conformity with national law.
18. Determination of Responsiveness
After the official opening of Tenders, LGMA, its staff or agents will determine whether each Tender is substantially responsive to the requirements of the
Invitation to Tender.
If a material deviation exists that limits in any substantial way LGMA’s rights or the Tenderer’s obligations under the Contract, the Tender may be rejected. A material deviation is one which affects in any substantial way the price, scope, quality, completion or timing of the proposed contract to be undertaken by the Tenderer or which limits in any substantial way the Purchaser’s rights or the Tenderer’s obligations under the contract.
A tender determined to be non-responsive shall be rejected by LGMA and may not be subsequently made responsive by correction of the nonconformity. The tender will be considered only on the basis of the responsive contract lots. The Purchaser may waive any minor nonconformity or irregularity in a tender which does not constitute a material deviation, provided that the waiver does not prejudice or affect the relative ranking order of any tender.
19. Clarification of Tenders
LGMA may ask Tenderers for clarification of their Tenders, including breakdowns of unit prices. No change in the price or substance of the Tender shall be sought, offered or permitted. To assist in finalising the tender evaluation, selected tenderers may be invited to attend clarification meetings with LGMA or its agents. The attendance of key people assigned by the tenderer to the proposed project will be essential.
20. Reference site visits
LGMA and its agents may at their discretion visit reference sites without the presence of the tenderer.
Draft 9.2: Page 85 of 94

21. Correction of Errors
Where there is a discrepancy between the hard copy and the electronic copy of a tender, the hard copy will take precedence.
Where there is a discrepancy between amounts in figures and words, the amount in words shall apply.
Where there is a discrepancy between the unit price and the total amount derived from the multiplication of the unit price and the quantity, the unit price will normally govern.
The amount stated in the tender form will be adjusted by LGMA in accordance with the above procedure and, with the agreement of the tenderer, shall be considered as binding upon the tenderer. Without prejudice to the above, a tenderer not accepting the correction of their tender as outlined shall have their tender rejected.
The above procedure shall be binding upon the tenderer and a tenderer not accepting the correction of their tender as described above shall have their tender rejected.
22. Change in the Composition of a Tender
LGMA reserves the right, but is not obliged, to disqualify any Tenderer that makes any change to its composition after submission of a Tender.
23. Interference
Any effort by the tenderer to unduly influence LGMA or its agents, relevant agency personnel or any other relevant persons or bodies in the process of examination, clarification, evaluation and comparison of tenders and in decisions concerning the Award of Contract shall have their tender rejected.
In accordance with Section 38 of the Ethics in Public Office Act 1995 any money, gift or other consideration from a person holding or seeking to obtain a contract will be deemed to have been paid or given corruptly unless the contrary is proved.
Draft 9.2: Page 86 of 94

24. Inducements to Purchase
LGMA shall be entitled to terminate any contract and to recover from the service provider the amount of any loss resulting from such termination in the following circumstances: i.
If the supplier has offered or given or agreed to give to any person any gift or consideration of any kind as an inducement or reward for doing or forbearing to do, or for having done or forborne to do, any action in relation to the obtaining or execution of this Agreement or any other contract with LGMA, or showing or forbearing to show favour or disfavour to any person in relation to this Agreement or any other contract with the
Client, or ii.
If like acts have been done by any other person employed by the supplier or acting on its behalf (whether with or without the knowledge of the supplier).
25. Notification of Tender Evaluations
Following tender evaluation all tenderers will be informed formally of the outcome in accordance with EU procurement law requirements.
26. Award of Contract
In accordance with the procurement regulations LGMA will not award the contract for a period of at least 14 days (where notification is sent via electronic means) or 16 days (if notification is sent by other means) after notification of the outcome is sent to tenderers.
When appropriate an award notice will be despatched to the Official Journal of the European Union announcing the results of the competition no later than
48 days after the award of the contract. It should be noted that it is standard practice for the Client to include the price of the winning tender or the range of prices of tenders received in the publication of the award notice as required under European procurement rules.
LGMA reserves the right not to proceed with the competition at any stage or not to award a contract.
Draft 9.2: Page 87 of 94

27. Payment
All quotations and terms of payments shall be in Euro only. Payment for any orders will be on foot of invoices for each completed part of order and made only after delivery and inspection. The consortium undertakes to make all payments solely under the terms of the European Communities (Late
Payment in Commercial Transactions) Regulations 2002. Detailed invoicing arrangements will be agreed with the successful supplier(s)/service provider including arrangements for staged payments.
28. Award to runner up
If for any reason it is not possible to award the contract to the designated successful tenderer emerging from this competitive process, or if having awarded the contract, the contracting authority considers that the successful tenderer has not met its obligations, the contracting authority reserves the right to award the contract to the next highest scoring tenderer on the basis of the terms advertised. This shall be without prejudice to the right of the contracting authority to cancel this competitive process and/or initiate a new contract award procedure at its sole discretion.
29. Possible TUPE Considerations
Participants are advised that in the event of significant transfer of undertakings, businesses or parts of businesses, the provisions of SI 131 of
2003 European Communities (Protection of Employees on Transfer of
Undertakings – TUPE) Regulations 2003 may apply. The successful tenderer will therefore be required to indemnify the contracting authority fully in respect of any losses, damages, costs or expenses of any kind incurred arising from their compliance with the TUPE Regulations.
At tender stage, tenderers will be required to inform themselves by their own enquiries as to the potential applicability of the TUPE Regulations and to take this factor into account when preparing their tenders, which will be deemed to include all the potential costs likely to be incurred as a result of any ensuing obligations under TUPE.
Draft 9.2: Page 88 of 94

Library Authority Pop. Borrowers Staff Staff
Terminals
Dublin City
Dún Laoghaire-
Rathdown
Fingal
South Dublin
Carlow
Cavan
Clare
527,612 151,303
206,261 72,195
273,991 160,308
265,205 81,535
54,612 8,329
73,183 12,279
117,196 19,964
Cork City
Cork County
Donegal
Galway
Kerry
Kildare
Kilkenny
Laois
119,230 21,304
399,802 58,523
161,137 87,115
250,653 40,544
145,502 23,273
210,312 65,635
95,419
80,559
11,812
11,504
Leitrim 31,798 6,439
Limerick City & County 191,809 34,915
Longford
Louth
Mayo
Meath
39,000 8,164
122,897 17,347
130,638 28,736
184,135 25,803
281.9 128
69.80 70
104.50 92
96.30 71
13.55 20
20.55 14
50.20 50
72.80 84
98.07 105
41.91 45
56.0 51
42.0 31
58.86 55
29.86 37
21.92 28
17.08 31
58.55 64
21.75 13
28.90 29
30.40 1
39.02 40
0
2
0
0
2
1
1
0
1
5
0.5
1
0
2
4
4
0
0
0
9
15
8
10
7
28
13
29
9
20
9
7
4
9
17
6
5
17
12
1
6
3
1
0
2
11
2
0
4
15
13
0
1
0
1
0
41
6
Selfservice kiosks
19
15
Branches Mobiles Items
24
8
2
0
Records Issues p.a.
1,441,398 482,060 2,491,811
432,634 385,207 1,378,989
938,748
695,128
164,673
199,948
345,842
409,210 1,192,968
316,255 1,150,670
164,673 203,255
100,813 186,676
147,667 566,645
487,180 270,000 1,011,062
1,153,067 330,757 1,797,500
386,848
616,000
207,520 371,571
225,000 657,818
362,510
492,997
238,889
200,748
134,549
598,098
147,343
362,510 592,060
212,460 724,464
203,217 295,262
158,849 290,720
133,549 117,848
420,815 777,482
147,343 132,565
322,051
406,846
457,632
261,292 537,666
215,914 631,216
216,494 583,721
Draft 9.2: Page 89 of 94

Library Authority
Monaghan
Offaly
Roscommon
Sligo
Tipperary JLC
Waterford City
Waterford County
Westmeath
Wexford
Wicklow
Pop. Borrowers Staff Staff
Terminals
60,483 29,342
76,687 14,276
64,065 8,344
65,393 13,138
158,754 24,172
46,732 44,170
67,063 12,861
86,164 15,078
145,320 56,793
136,640 32,777
22.70 28
19.01 22
21.0 24
19.45 27
51.0 41
20.0 30
18.20 11
23.70 30
35.0 40
28.47 23
3
0
1
2
0
5
1
4
9
5
Selfservice kiosks
Branches Mobiles Items
5
8
6
4
12
3
7
7
5
13
1
0
0
0
1
0
1
0
2
1
138,488
230,000
261,243
213,088
431,745
268,101
126,400
354,806
411,935
346,121
Records Issues p.a.
73,146 271,184
230,000 248,441
209,822 216,128
177,911 263,108
187,665 502,707
178,186 400,097
126,400 263,928
169,404 375,908
342,473 660,663
184,559 521,961
Library authority structures are under review at present. From July 2014, Limerick City and County will be merged into a single authority. Waterford City and County will be merged into a single authority and Tipperary Joint Libraries Committee will become
Tipperary libraries. Other changes may result from the review process.
Draft 9.2: Page 90 of 94

Library Authority Current LMS
Dublin City Axiell Galaxy V6 (non-Windows) + Axiell Open Galaxy V3.113
Dún Laoghaire-Rathdown Open Galaxy 3.14 & Galaxy Version 6
Fingal
South Dublin
Open Galaxy 3.113
Axiell Open Galaxy V 3.113
Carlow
Cavan
Clare
Cork City
Cork County
Donegal
Galway
Kerry
Horizon 7.2.3
Horizon 7.5.1
Innovative’s Millennium LMS
Horizon 7.5
Horizon 7.5
Horizon 7.5
Horizon 7.5
Horizon 7.5.2
Kildare
Kilkenny
Laois
Leitrim
Limerick City
Limerick County
Longford
Louth
Mayo
Meath
Monaghan
Offaly
Roscommon
Sligo
Tipperary JLC
Waterford City
Waterford County
Westmeath
Wexford
Wicklow
Horizon 7.5
Horizon 7.5.1
Horizon 7.5
Horizon 7.4.106.20
Horizon 7.4
Horizon 7.5.1
Horizon 7.5.1
Horizon 7.5
Horizon 7.5
Horizon 7.5
Sirsidynix Symphony Workflows 3.4.1.2.1051
Horizon 7.5
Horizon 7.4.2
Java SirsiDynix Workflows 3.4.1.2
Horizon 7.5
Horizon 7.5.2
Horizon 7.3.4
Horizon 7.5
SirsiDynix Symphony 3.4
Horizon
Draft 9.2: Page 91 of 94