CGA_SOW_6_24_2022.docx

Statement of Work

Library Services Platform USCGA Library / United States Coast Guard Academy

1. Background

The United States Coast Guard Academy (USCGA) prepares future Coast Guard officers. Over 1,000 cadets reside on campus and will earn an accredited Bachelor of Science degree in one of six majors and then serve for a minimum of five years in the U.S. Coast Guard. USCGA’s goal is to develop officer-ready leaders of character who embody Coast Guard values, who influence and inspire others, and who decide what is right and demonstrate the courage to act accordingly.

The USCGA Library’s mission is to foster and promote an inclusive environment of learning, exploration, and innovation to encourage the growth, success, and empowerment of the Academy community. The Library supports the cadets’ ability to improve their research skills in an ever-changing environment, a skill that is vital to their success as officers in the field.

The USCGA Library tracks over 58 current database subscriptions of journals and books as well as purchasing e-book packages, tracking user driven e-book and streaming video purchase programs, and maintaining a print collection of around 100,000 titles.

2. Scope

In order to maintain library performance, provide modern services for their patrons, and improve academic success, the USCGA Library requires a new Library Services Platform (LSP). A new LSP will improve system security as well as streamline and automate workflows. The LSP must be a cloud-based system that is compliant with all Department of Homeland Security (DHS) and United States Coast Guard (USCG) security requirements. Additionally, the existing ProQuest’s Summon discovery service shall be replaced with a new discovery service to effectively synchronize with the new LSP.

To achieve and promote student success, the USCGA Library must modernize its current infrastructure to support its mission consistent with modern academic library structures in order to meet the standards of current librarianship. A critical tool for success is a LSP that enables the library to acquire, manage and augment all forms of resources, including print and electronic monographs, serials, media, and databases. It also allows for management of patron records, cataloging, and other library functions. The USCGA Library selected its current ILS, SirsiDynix Symphony, in 1998. It is locally hosted at the USCGA with client instances on each Library staff machine. This was supplemented with Serials Solutions for electronic journal discovery which was upgraded to include 360Link and 360Search. In 2015, the Library replaced 360Search with Summon as its discovery layer. At this time, our ILS is a mature data product that no longer receives critical updates. It also does not offer multiple features and developments that have become commonplace in mainstream integrated library systems. The discovery layer is separate from the ILS, which is awkward, labor-intensive, and inefficient. Replacing Symphony and Summon with a new, modern LSP with an integrated discovery layer is critical to the continued operations of the USCGA Library and the successful education of the USCGA cadets.

The LSP should replace SirsiDynix Symphony (ILS), ProQuest’s 360 Link, ProQuest’s Summon, and various other disparate systems currently in use. It should reduce redundancy, streamline work for multiple units in the library, and support both existing and new library technologies.

The USCGA Library requires all data to migrate from the current implementation of SirsiDynix Symphony to the new LSP. There must be no system downtime between the deactivation of the old ILS and the implementation of the new LSP during this transition.

The vendor will need to create a data migration plan and implementation plan, and coordinate with the library at all steps of the transition to the new system. The vendor will deliver the LSP, which is described in detail in section 3.

After delivery of the LSP, the vendor will provide ongoing technical maintenance and customer support to the library and continue to provide updates to the LSP over time.

Contract shall be awarded prior to9/30/2022 and only planning/implementation costs charged at that time. New LSP must go live by 8/1/2023 and annual subscription/maintenance costs shall be charged at that time.

The timeline is divided into analysis, planning, implementation, testing, and ending of existing system to prevent a break in services.

Planning/Implementation Phase

Post-award meeting with contractor

Planning phase

Initial Staff training

Migration testing

Data migration

Onsite workflow management training and consultation

System configuration complete

Staff training in local sandbox

Final configuration complete

Go live

Subscription/Maintenance Phase

Post-live system maintenance and corrections

On-site consultation/work flow analysis during base year

System support and customer support included as a part of ongoing subscription

3. Requirements

The contractor shall support migration from the existing SirsiDynix Symphony ILS to a multi-tenant SaaS library services platform.

3.1 System Requirements:

3.1.1 The system shall allow unified management of all print, electronic, and digital resources that USCGA owns, licenses, and makes available to end users for discovery and delivery. This includes acquisition support for both physical and electronic resources, metadata management across all resource types, and fulfillment across all resource types.

3.1.2 The system shall include in the base package, at the point of purchase, the following live components:

a. Acquisitions

b. Request fulfillment & circulation

c. Metadata management

d. Administration

e. Link resolution

f. Knowledgebase

g. Analytics

h. Discovery

i. Print and Electronic Resource Management

j. Asset management

3.1.3 The new system shall ensure that the library can, upon migration, decommission the following local systems:

a. SirsiDynix Symphony ILS

b. ProQuest 360 Link

c. ProQuest Summon

3.1.4 The system shall interface with OCLC Worldcat Connexion, Gobi, and other third- party acquisitions and cataloging resources.

3.1.5 The system must not rely on third-party applications or providers.

3.1.6 The system shall have cloud-based architecture and hosting that does not require installing software on customer equipment.

3.2 System - Staff Search Requirements:

3.2.1 The system shall offer intuitive and easy to use search methods; both basic and advanced searching shall be supported.

3.2.2 The system shall have an advanced search that shall allow for the option of searching multiple fields simultaneously for words or phrases. Staff should be able to define their own search conditions – based on standard indexed options. Search shall support Boolean operators.

3.2.3 The system shall be delivered with out-of-the-box set of indexed fields, including, but not limited to:

a. Author

b. Title

c. Periodical Title

d. Subject

e. Call number

f. Series

g. ISBN/ISSN

3.2.4 It shall be possible to search across all types – bibliographic, physical, digital, electronic - in one search query.

3.2.5 It shall be possible to search by local call numbers.

3.2.6 It shall be possible to save and manage sets of staff queries.

3.2.7 It shall be possible to search for electronic resources by, but not limited to: title (e.g. journal title), package, and by provider.

3.2.8 Dependent on the search type, it should be possible – from the results list - to edit a record, create an order, view holdings, items, and other connected information.

3.2.9 It should be possible to sort result sets by various parameters – e.g. ranked, title, author. There should be more than one level of sorting.

3.2.10 The system should navigate the user to a personalized dashboard when logging in.

3.2.11 It should be possible to post widgets of report outputs on the dashboard.

3.2.12 It should be possible to add/remove/reorder the widgets on the dashboard.

3.3 System - User Management Requirements:

3.3.1 The system shall support a web-based interface for assigning roles and permissions to staff functions.

3.3.2 The system shall provide granular access control rights for staff accounts and be able to facilitate multiple profiles accessing different combinations of functional areas.

3.3.3 The system shall support the option of defining role templates, which can then be easily assigned to new users.

3.4 System - System Administration and Management Requirements:

3.4.1 The system shall come with a set of “Out of the Box” definitions and configurations so that the library need only make minimal changes to the standard settings.

3.4.2 The system shall allow authorized staff to configure various aspects of the system without vendor intervention.

3.4.3 The system shall allow for customizing the acquisition workflows in order to accommodate specific library needs, as well as control over when orders and invoices need mediated handling.

3.4.4 The system shall allow the library to configure when fulfillment processes such as hold request/call slips can be automated or need to be mediated.

3.4.5 The system should come with the ability to add notes and file attachments to various resources managed in the system.

3.4.6 The system shall display ‘created by,’ ‘last updated by,’ and (where applicable) ‘modified by’ information for various types of records.

3.4.7 The system shall be a Web-based multi-tenant SaaS solution that requires only a Web browser, not the installation of staff clients.

3.4.8 The system shall have a web interface architecture that is customizable and modifiable by USCGA Library staff.

3.4.9 The system shall have support for various web browsers across multiple platforms (Windows, macOS, Android, iOS, etc.) for both staff and end-users.

3.4.10 The system shall have support for single sign-on authentication and authorization systems.

3.4.11 The system shall support streamlined, efficient workflows without duplicative or otherwise redundant work.

3.4.12 The system must support customizable alerts or notifications to staff via some combination of pop-up windows, sound alerts, and e-mails in response to actions such as circulation transactions and licensing deadlines.

3.4.13 The system shall support record templates, shortcut keys, macros, and scripts that can be implemented on the staff interface for workflow automation.

3.4.14 The system shall be Section 508 compliant.

3.5 Acquisitions Requirements:

3.5.1 The system shall support automated workflows including:

a. Print approval

b. Print firm order

c. Electronic firm order

d. Print continuation

e. Electronic subscription

f. Patron-driven acquisitions

g. Evidence-based acquisitions

3.5.2 The system shall be able to automatically create purchase orders based on vendor-supplied machine-readable cataloging (MARC) records and electronic order confirmation records (EOCR), for resources ordered in external systems.

3.5.3 The system shall provide links from a purchase order to other related information.

3.5.4 The system shall support a full electronic data interchange (EDI) interface with major library vendors for ordering and invoicing.

3.5.5 The system shall support setting up trials for both electronic collection packages and databases to evaluate e-resources before purchasing.

3.5.6 The system shall support the ability to evaluate existing e-resource subscriptions and decide to renew or cancel based on parameters such as usage and cost.

3.5.7 The system shall allow for the activation of approved purchases for electronic packages and titles.

3.5.8 When an electronic package or title is activated, descriptive records to describe the title(s) shall be added to the local catalog automatically.

3.5.9 The system shall support the ability to perform an overlap analysis report for electronic resources, including the ability to upload a list of titles (using an Excel or .CSV file) that the library is considering acquiring in order to determine whether the titles are part of the library’s existing collection.

3.5.10 The system shall allow financial data to be imported from or exported to commonly used formats such as CSV, TSV, and Excel.

3.5.11 The system shall allow funds to be established and managed via encumbering, disencumbering, adjusting, and expending funds.

3.5.12 The system shall provide real-time access to fund balances.

3.5.13 The system must support Federal Fiscal year close out-processing.

3.6 Acquisitions - Invoices and Payments Requirements:

3.6.1 The system shall support the ability to automatically create an invoice from the purchase order.

3.6.2 It shall be possible to manually create an invoice, or to load invoices from an Excel file in the system.

3.6.3 An invoice/license audit history shall be available in the system.

3.7 Acquisitions - Claims Requirements:

3.7.1 The system shall provide automatic claiming for items not received within an expected number of days after placing the order; such intervals shall be based on library-defined date and time parameters

3.7.2 It shall be possible to manually generate claims (on demand).

3.7.3 The system shall support EDI claiming.

3.8 Acquisitions - Receiving Requirements:

3.8.1 The system shall allow print items to be received either as part of the invoicing process, or as a separate process.

3.8.2 The system shall be able to automatically create new item records when an item is received, or if items are created at the time of acquisitions, the system shall allow for updating item information.

3.8.3 The system shall notify staff when a volume or issue of a series has not arrived after a predefined interval, and allow for claiming of missed items.

3.8.4 The system shall identify where to route received items based on the completeness of their metadata and item information.

3.8.5 The system shall be able to process receipt of monographs, serial monographs, serials, subscriptions, and standing orders.

3.9 Acquisitions - Subscription Vendor Requirements:

3.9.1 The system shall provide the ability to maintain multiple accounts for a single vendor.

3.9.2 The system shall provide the ability to maintain multiple physical and e-mail addresses for a single vendor, with the potential to tie these addresses to individual accounts.

3.9.3 The system shall offer the ability to maintain discount and delivery and claim information in the vendor record.

3.9.4 Invoices linked to a vendor shall be linked to the vendor record.

3.9.5 It shall be possible to include vendor-specific EDI information.

3.9.6 Vendor records shall be able to link to all appropriate vendor-related invoices.

3.9.7 The vendor record shall include links to all purchase orders made against the vendor.

3.10 Cataloging Requirements:

3.10.1 The system shall support multiple metadata formats and be extensible to additional formats. At a minimum, MARC21, UNIMARC and Dublin Core shall be available out-of-the-box for the library, with future support for other formats.

3.10.2 The system shall support multiple classification schemes including at least Library of Congress classification, SuDoc, and local classification.

3.10.3 The system shall allow staff to create, edit, and delete records in any of the system-supported formats.

3.10.4 The system shall support import and export (with no loss of data) in all system-supported formats.

3.10.5 The system shall have embedded support for RDA including the indexing of RDA specific elements.

3.10.6 The system shall support validation of appropriate use of elements, fields, subfields, and values, including validation of controlled vocabularies for fields.

3.10.7 The system must provide the ability to locally edit and customize all record types and bibliographic fields.

3.10.8 The system must provide the ability to batch load and batch edit large sets of MARC records obtained from OCLC WorldShare, Marcive, CDRP, and other publishers.

3.10.9 The system shall be able to suppress all types of records on demand.

3.10.10 The system shall provide a link-check function.

3.10.11 The system shall support non-English language characters in the system.

3.11 Cataloging - Editing Requirements:

3.11.1 The system shall 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.

3.11.2 The system shall 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.

3.11.3 The system shall support record versioning, including the ability to view and roll back to past versions of that record.

3.11.4 The system shall support hotkeys for navigation and actions that allow editing entirely with the keyboard.

3.11.5 The system shall 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.

3.11.6 The system should support the option of library defined merge routines that can be applied to records imported in bulk or one by one in the catalog editor.

3.11.7 It shall be possible to link an electronic, digital, or physical item to one metadata record.

3.11.8 The system shall provide the ability to derive a new bibliographic record from an existing record.

3.11.9 The system shall allow global changes of item and order records within the system.

3.11.10 The system shall support EAD as an exchange format, including exporting collections as EAD files.

3.11.11 The system shall support a tool for printing labels.

3.12 Cataloging - Authority Control Requirements:

3.12.1 The system shall provide access to global, shared authority files without the need for individual libraries to synchronize with the authorizing agency. The files should include Library of Congress Subject Headings and Names.

3.12.2 The system shall allow staff to create or load local authority files and records for subjects (including genre terms) and names.

3.12.3 When a heading changes in a local or global authority record, the system must automatically make the change in bibliographic records that are authorized against that heading without staff intervention.

3.13 Cataloging - Holdings Management Requirements:

3.13.1 The system shall support the MARC21 format for holding records.

3.13.2 The system shall allow for the creation of holdings and item records for physical resources.

3.13.3 The system shall support holdings statements of serial and non-serial multipart items as defined in ANSI/NISO Z39.71.

3.13.4 The system shall support the ability to perform changes in bulk against a set of holdings or items.

3.13.5 The system shall support the recording of missing/lost items.

3.13.6 The system shall support the suppression of records from the discovery layer.

3.14 Cataloging - Importing Records Requirements:

3.14.1 The system shall allow for the loading records singly or in bulk.

3.14.2 The system shall allow for searching external databases through the online interface via z39.50 or Search and Retrieval via URL/Web service (SRU/W) protocols and importing resulting records to the catalog. Copy cataloging shall be done within the system, without requiring separate login.

3.14.3 The system shall allow for the enhancement of incoming records according to library-defined bulk record change rules. When loading a record or set of records, staff shall have the following options for handling records detected as duplicate:

a. Add new records, ignoring duplicates

b. Overlay one record with another

c. Merge the two records

d. Not load new records when a duplicate is detected

3.14.4 The system shall prevent the overlay of a non-brief record by a brief record on import.

3.15 Cataloging - Exporting Records Requirements:

3.15.1 The system shall allow for the export of individual, groups of records, or an entire catalog to a predefined target with no additional fees. The records to be exported may be based on a selected set, or records that have changed since the last export to that target.

3.15.2 The system shall 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.

3.16 Cataloging - Shared Bibliographic Records Requirements:

3.16.1 The system shall provide access to a catalog of bibliographic records shared by all libraries of that system. Libraries shall be able to attach holdings directly to the shared records, edit the records, or copy them from the shared catalog to the libraries’ local catalog.

3.16.2 Members of the consortium shall be able to update or edit records in the shared catalog, according to set standards.

3.16.3 The system shall support a local catalog in addition to the shared catalog for storing records that have local descriptive needs or terms of use that prevent their being shared with other libraries. Libraries shall be able to use the shared catalog, the local catalog, or both simultaneously.

3.16.4 The system shall support the addition of local fields to the shared records that are viewable only to the local library.

3.16.5 For consortia, the solution shall allow for sharing bibliographic metadata across the consortium, while at the same time allowing individual libraries to record and maintain information of local importance.

3.17 Circulation Requirements:

3.17.1 The system shall have the capacity to manage all types of library material, e.g. books, serials, electronic resources, digital materials, electronic equipment, etc. This will include at least changing item status, on-the- fly patron, item, or bibliographic records, and placing holds.

3.17.2 The system shall support ANSI/NISO z39.83 (NISO Circulation Interchange Protocol) in the base package to facilitate lending and borrowing actions between systems.

3.17.3 The system shall provide integration with ILL software, using standard protocols.

3.17.4 The system shall include an offline circulation component with the ability to upload transactions into the system once the network issue is resolved.

3.17.5 The system shall support self-service machines.

3.17.6 The system must provide ability to automate a bulk user load process (i.e., new incoming students each semester) to bulk import patron records from an external source at no additional charge.

3.17.7 The system must be able to activate or deactivate patron checkout history.

3.17.8 The system must support the ability for staff to charge and renew multiple items in a single session without the need to enter an “override” for each item in the same session.

3.18 Circulation - Customer Management Requirements:

3.18.1 The system shall provide the ability to create different customer types and set circulation parameters for each customer type.

3.18.2 It should be possible to define more than one customer identifier linked to a customer record.

3.18.3 The system shall allow authorized staff to create, modify, and delete customer records.

3.18.4 Customer information shall be updateable through an application programming interface (API) via customer relationship management systems that serve as the initial source of that customer information.

3.18.5 The system shall integrate with external identity management systems (e.g. LDAP/Shibboleth) for authentication.

3.18.6 It shall be possible to update defined areas of each customer record in the system. Customers shall be able to have multiple addresses.

3.19 Circulation - Fulfillment Policy Requirements:

3.19.1 The system shall be able to define the policies by which the library’s physical inventory is circulated to library customers.

3.19.2 The system shall provide extensive ability to set parameters including for loans, limits, and calendar.

3.20 Circulation - Request Fulfillment Management Requirements:

3.20.1 The system shall support business rules that automatically manage customers’ requests, requiring staff user mediation only when necessary.

3.20.2 When placing a request it shall be possible to define if the request is for digitization or for a physical item.

3.20.3 A customer-initiated digitization request shall trigger an alert and a pick slip at a specific digitization location.

3.20.4 The system shall automatically generate a notice to customers when requested items are available.

3.20.5 The system shall support the administration of access rights for digital materials, based on customer group and collection.

3.20.6 The system shall support the administration of access rights for electronic materials, including the ability to restrict access by IP address.

3.20.7 The system shall support hold queue priority.

3.20.8 The product shall support digitization on demand workflows.

3.21 Circulation - Interlibrary Loan (ILL) Requirements:

3.21.1 The system shall support ILL functionality – both for borrowing and lending.

3.21.2 There shall be support for at least one of the following ILL software solutions, e.g., ILLiad, OCLC Worldshare ILL, or Relais D2D.

3.21.3 The system shall support RapidILL or some other peer-to-peer, unmediated ILL.

3.21.4 The system should support the ISO 1060/10611 ILL protocols.

3.21.5 The system shall be able to allocate a unique request number as each request is created on the system.

3.21.6 The ILL component shall link to and be fully integrated with other components within the discovery system.

3.21.7 The system shall provide a ‘status history’ function to record all changes and updates within the ILL request record.

3.22 Circulation – Controlled Digital Lending (CDL) Requirements:

3.22.1 The system shall support CDL functionality – for both borrowing and lending.

3.22.2 There shall be support and integration for systems which provide encrypted downloads that expire after a set time period.

3.22.3 The system shall be able to provide usage and statistics related to CDL.

3.22.4 The CDL component shall link to and be fully integrated with other components within the discovery system.

3.22.5 The system shall provide a way to track all changes and updates with regards to CDL borrowing or lending.

3.23 Course Reserve Requirements

3.23.1 The system must provide the ability to seamlessly update bibliographic and item records while working inside the course reserves module.

3.23.2 The system must provide the ability to assign different loan periods at the copy level to individual titles that have multiple copies.

3.23.3 The system must provide the ability to assign course reserves to one or more instructors and course numbers at the item/copy level.

3.23.4 The system must provide the ability to prevent patrons from placing holds or recalls on reserve items. The system must allow for holds to be placed on available items.

3.23.5 The system must provide the ability to manage materials that alternate locations between “general circulation” and “course reserves,” while maintaining individual and separate statistics for these items (for example, general circulation vs. reserve circulation).

3.24 Electronic Course Reserve Requirements

3.24.1 The system must provide the ability to link to USCGA Library licensed or locally-held content (eBooks and articles) at the item level.

3.24.2 The system must provide the ability to activate and suppress course reserves on a quarterly basis while retaining information and statistics from prior quarters.

3.24.3 The system must provide the ability to batch process reserve items.

3.24.4 The system must integrate with external e-learning systems (such as Blackboard).

3.25 Discovery Layer Interoperability Requirements:

3.25.1 The discovery system shall support a complete and transparent integration with a next-generation library services platform.

3.25.2 The system shall support seamless customer-driven workflows initiated from discovery and served by the system such as, but not limited to: digitization on demand, customer-driven acquisition, ILL requests, and course reserve requests.

3.25.3 The discovery system shall support discovery and delivery of all resource types: physical, electronic, and digital, as well as discovery by collections.

3.25.4 The discovery layer shall allow for local library resources to be searched either on its own or combined with other resources.

3.25.5 The discovery layer shall display item availability and public notes for local library resources.

3.25.6 The discovery layer shall provide citation services such as printing, e-mailing, and exporting to citation management software.

3.25.7 The discovery layer shall provide persistent links to result items, bookmarks, and saved search queries.

3.25.8 The system should have the ability to publish records to discovery with enriched headings information from the shared catalog.

3.25.9 The system shall publish authentication and public notes for display to the customer.

3.25.10 Customers shall be able to see all of their account information (loans, requests, saved searches, etc.) in the library’s discovery solution as well as the option to change their personal settings.

3.25.11 The system shall present to customers options to fulfill customer requests across all relevant resource types. The system should include a citation linker to request services for a specific article, book, or journal either through the library or as a resource sharing request.

3.25.12 The system shall provide, as well as support, published APIs or Web Services to facilitate interoperability with external services.

3.25.13 The discovery solution shall de-duplicate search results.

3.25.14 The discovery solution shall allow the library to adjust the algorithm used for relevancy ranking.

3.25.15 The solution shall include personalized ranking to tailor search results based upon end-user research preferences.

3.25.16 The solution shall be delivered with a mobile phone interface.

3.25.17 Discovery shall work with and across consortium content. Consortium members should be able to provide a customized view to their users.

3.25.18 The system shall support the ability to display an online resource’s license information to end users in the discovery interface.

3.25.19 The system shall interoperate with an integrated reading list for the creation, maintenance, and use of course reading lists.

3.25.20 The system shall provide complete integration for discovery, access, and management of all USCGA Library databases, journals, and eBooks.

3.26 Electronic Resource Management (ERM) Requirements:

3.26.1 The digital objects that are currently managed by the institution’s existing digital asset management system shall be both migrated and stored within the unified resource management repository, or they can continue to reside in their current storage environment but be managed by the unified resource management system.

3.26.2 The system shall support bulk upload of files.

3.26.3 Digital collections managed by the library services platform shall be made discoverable in the discovery layer.

3.26.4 The system shall support predefined workflows for the upload of digitized material and their metadata.

3.27 ERM - Link Resolution Requirements:

3.27.1 The system shall include built-in OpenURL link resolution and context-sensitive services.

3.27.2 The system shall be able to augment the OpenURL metadata.

3.27.3 The system shall provide users with the ability to link directly to full-text content.

3.27.4 The system’s electronic journals shall be searchable via a journal search interface in the discovery layer.

3.27.5 The system shall be able to display license terms as part of the services offered in the end-user interface.

3.27.6 The system shall be able to assign accurate access rights to the correct populations of users.

3.28 ERM - Digital Asset Management Requirements:

3.28.1 The system shall be supported by a comprehensive Knowledge Base that is automatically updated when vendors change metadata and content in their proprietary databases; for example, resources from vendors such as ProQuest, JSTOR, Wiley, Sage, Springer, and others.

3.28.2 The following vendors must be included in the vendor’s Knowledge Base: ACM, ACS, ASCE, ASME, ASM, Clarivate, CQ Press, EBSCO, Elsevier, Gale, HeinOnline, IEEE, IGI Global, InfoBase, JSTOR, Janes, Kanopy, McGraw-Hill, Mergent, NewsBank, Oxford University Press, ProQuest, Sage, Springer, Statista, Taylor & Francis, Westlaw, and Wiley.

3.28.3 The system shall provide an Electronic Resource Management (ERM) application to allow for the management, analysis, and evaluation of e-resources.

3.28.4 The system shall support management and display of license terms and conditions in machine- readable format to include linkage to digital resources, communicating key usage terms to users, and comparing terms across different licenses.

3.28.5 The system shall allow for the creation and display of both internal and public notes for ERM records.

3.28.6 The Knowledge Base should be updated at least once a month.

3.28.7 The organization of the Knowledge Base shall accommodate the different levels of electronic resources information.

3.28.8 The Knowledge Base should support accurate data that facilitates resource discovery.

3.28.9 The system shall allow for the addition of titles not currently in the Knowledge Base.

3.28.10 Knowledge Base must support DDA and other usage-based collection management programs.

3.29 ERM - Licenses Management and Amendments Requirements:

3.29.1 The system shall be able to manage licenses and amendments, including attaching digital versions.

3.29.2 License management shall be included in the system and not require additional setup or fees.

3.29.3 License fields should be customizable, with the ability to display only those fields that the library uses, excluding others if the library so chooses.

3.29.4 The system shall enable license terms to be displayed to the end user. The terms that are displayed as well as the labels should be configurable.

3.30 ERM - Reporting and Analytics Requirements:

3.30.1 The system shall include a comprehensive analytics component that covers all of the LSP data and is an integral part of the system.

3.30.2 The analytics component shall form part of the standard package at no additional cost.

3.30.3 The system must have the ability to compare titles across at least 10 databases simultaneously.

3.30.4 It shall be possible to utilize canned reports provided by the vendor.

3.30.5 The reporting tool shall have analytics tools that integrate analytics into typical workflows - e.g., including usage and cost information as part of standard selection.

3.30.6 The reporting tool shall support a variety of output options including, but not limited to viewable online, send to printer, e-mail, and export to a spreadsheet.

3.30.7 The reporting system shall support the customization of reports by librarians; this includes, but is not limited to: changing of reports parameters, views, time range, etc.

3.30.8 The reporting system shall support the ability to collaborate and share reports made by other parties.

3.30.9 The reporting system shall support the ability to collaborate and share reports with other parties.

3.30.10 The reporting solution shall be able to provide usage statistics reports and comply with industry usage reporting standards such as SUSHI and COUNTER.

3.30.11 The solution shall support role-based report generation and viewing such that a user will only be able to view reports and data according to their role.

3.30.12 The solution shall include a dashboard in which it is possible to monitor performance, view user- specific tasks, and detect trends. Information in the dashboard shall be based on staff user roles, allow for customization, and support the embedding of widgets.

3.30.13 The tool shall be able to analyze history data and provide trends analysis.

3.30.14 The reporting application shall allow for the automatic scheduling of reports at defined intervals.

3.30.15 The reporting application shall provide cost-per-use reports.

3.30.16 The tool shall allow for report creation and filtering based on advanced user information or statistical categories.

3.30.17 The system shall store records, data, and reports from library processes indefinitely at no additional charge.

3.30.18 For consortia, the solution shall support the ability to run reports across institutions, for the purposes of cross-institutional reporting and comparisons.

3.31 Serials Management Requirements:

3.31.1 The system shall be able to automatically generate issue predictions for serials and prompt claiming of overdue new issues.

3.31.2 The system shall display current receipt status in the public display for the serial.

3.31.3 The system shall support check-in of issues received irregularly or with more than one copy per issue.

3.31.4 The system shall identify claimable issues, send claims individually or in a batch with EDI, and track claims history.

3.32 Support Services Requirements

3.32.1 USCGA will require in-person training sessions before implementation of the LSP, as well as an on-site post-implementation workflow analysis. Further training should take place both online and over the phone when requested by the USCGA Library.

3.32.2 The vendor shall provide up-to-date documentation for implementation, operation, and maintenance of system.

3.32.3 The vendor shall provide up-to-date documentation for security policies, procedures, and practices.

3.32.4 The vendor shall offer standalone capabilities and/or tools to allow the Library to continue core functions during power outages, system, or network downtime.

3.32.5 The vendor shall provide ongoing customer support such as troubleshooting and application advice during normal hours of USCGA Library operation.

3.32.6 The system should feature at least annual updates to all customers, released by the vendor and requiring no library IT intervention.

3.32.7 The vendor shall provide key personnel who will lead and manage the project plan, timeline, data migration, testing, and implementation phases which is expected to last through the base year.

3.32.8 The vendor shall support data migration from the current ILS (SirsiDynix Symphony) and electronic resource knowledge base (ProQuest Intota) (which is expected to occur during the base year), including

a. Bibliographic records (print and electronic)

b. Holdings in all formats (including print and electronic serials and associated holdings)

c. Order records

d. Patron data (including patron-associated checked out items)

3.32.9 The vendor must have an active national user group that meets at in person at least once a year.

3.32.10 The vendor shall support API development and sharing

3.33 Security Requirements

3.33.1 The system shall have cloud-based architecture and hosting that does not require installing software on customer equipment.

3.33.2 Vendor shall provide fully cloud-based architecture and hosting that does not require use of any locally-installed vendor-client software on customer equipment

3.33.3 System privacy and security will be determined and maintained in accordance with current Department of Homeland Security (DHS) and U.S Coast Guard (USCG) security standards.

3.34 Migration and Implementation Requirements:

3.34.1 Vendor shall provide a detailed migration plan that shall be approved by USCGA.

3.34.2 Vendor shall develop an implementation schedule in accordance with USCGA hours of operation, to ensure staff availability.

3.34.3 Vendor shall accommodate existing Symphony and discovery systems until full production deployment of new discovery system is completed and legacy systems are signed off for decommissioning.

3.34.4 The transition to a new LSP must not cause any system downtime.

4. Deliverables

4.1 Produces timeline and planning documentation.

4.2 Make data migration plan. Execute data migration.

4.3 Provide sandbox for staff training.

4.4 Provide monthly progress reports regarding planning, migration, training, and going live.

4.5 Deliver a new LSP meeting USCGA requirements.

4.6 Deliver a new discovery tool meeting USCGA requirements.

4.7 Demonstrate compliance with DHS and USCG security standards.

4.8 Provide staff training before and after the data migration and transition to new LSP, both online and in- person.

EVALUATION

The Government will award a contract resulting from this solicitation to the responsible offeror whose offer conforming to the solicitation will be most advantageous to the Government on the basis of "Best Value Evaluation" with the following technical evaluation factors which will be weighted equal to and or greater than price.

Technical factors:

· Technological Requirements

· Digital Asset management Requirements

· Proposed firm-fixed price and hourly rate

*Offerors must submit above information as part of RFQ package in addition to any other er documentation that verifies requirement of technical factors listed above*

SYSTEM FOR AWARD MANAGEMENT (SAM)

The selected consultant must have an active System for Award Management (SAM) account for contract award to be made (registration is free of charge), and have a valid Dun & Bradstreet DUNS number uniquely identifying their business in order for payment(s) to be made by the U.S. Coast Guard Finance Center (acquiring a DUNS number is also free, but may take up to 30 days). See https://www.sam.gov/SAM/ and https://www.dnb.com/duns-number.html for details.

RFQ PACKAGES. All responsible sources may submit a quotation, which if timely received, shall be considered by the agency.

Ensure to reference the solicitation number when submitting your quote.

The selected Offeror must comply with the following commercial item terms and conditions, in accordance with the FAR. Referenced FAR clauses are attached to this solicitation and may be accessed electronically at https://www.acquisition.gov/far/ .

Preference 19.502-2 Total small business | If no acceptable offers from responsible small business concerns are received, the set-aside shall be withdrawn and all acceptable offers will be accepted.

QUESTIONS. Interested offerors must submit any questions concerning the solicitation at the earliest time possible to enable the Buyer to respond.

Technical questions maybe address to:

Lucy Maziar (she/her/hers) Library Director US Coast Guard Academy 35 Mohegan Ave New London CT 06320

(860) 444-8517 lucia.maziar@uscga.edu https://libguides.uscga.edu

RFQ package questions must be submitted via email to david.f.palacios@uscg.mil | Ph: (860) 444-8245.

***Questions not received within a reasonable time prior to close of the solicitation may not be considered***