CONTRACT SPECIFICATION REQUIREMENTS FOR THE SUPPLY OF AN ERM SYSTEM FOR THE MANAGEMENT OF ELECTRONIC RESOURCES

The specification has been developed as part of the JISC funded MERI project at the University of Salford. More information about the project can be found at http://salfordmeri.blogspot.com/ .

The requirements have been compiled following a review of the processes used for electronic resource management at the University of Salford and also demonstrations of commercial ERM systems currently available. They are intended to be used and adapted by any other institution procuring an ERM system.

This document has been made available under a Creative Commons Attribution Share-Alike Non-Commercial 3.0 License

Instructions

Each criterion below has been rated using the MoSCoW method, a prioritisation technique used to indicate the importance of each requirement. The M/S/C/W ratings are explained as follows:
Must have
Should have if possible
Could have if it does not affect anything else
Would like to have

N.B. Some Requirements are simply a request for information, therefore the ‘Criteria Ref’ has been left blank.

Components

1. ERM system overview

2. Acquisitions

3. Licences

4. Access

5. Management and statistical information

6. Reports

REF
NO. / REQUIREMENT / Criteria Ref: /
1 / ERM System Overview
1.1 / What is the name of the system / -
1.2 / The system complies with the requirements of the data protection act. Please provide evidence / M
1.3 / The system complies with the requirements of the Disability Discrimination Act. Please provide evidence / M
1.4 / The ERM will comply with the institution’s system requirements, including servers, operating systems and any other dependencies on third party elements. Please describe how the system will interact with the University of Salford’s current systems as described in the background information / M
1.5 / Are you the sole owner of all the software to be supplied?
If not, please state who that is, and how licensing will operate and support be provided. / S
1.7 / The ERM works with LMS systems (for example Talis) Please give examples of work you have done with these systems. Please describe which areas of the LMS it is known to
a) work fully with
b) not work with
c) partially work with / S
1.8 / The ERM works with 3rd party link resolvers (e.g. SFX) and federated search systems (e.g. Metalib).
Give evidence of the possible level of integration of information. / M
1.9 / Details of holdings can be transferred between the ERM and the link resolver/search system.
Please provide examples of work you have carried out. / M
1.10 / The ERM works with finance systems (for example Agresso).
Please give examples of work you have carried out / C
1.11 / The ERM works with Resource Discovery Solutions (for example Primo Central).
Please provide examples of work you have carried out / C
1.12 / The ERM works with reading lists systems (for example Loughborough Reading List System)
E.g. the system can tell us if a resource is on a reading list and give details of the list
It automatically updates the record when a resource is taken off a reading list / S
1.13 / The system allows users to have different levels of access / S
1.14 / There is a procedure for submitting enhancement requests Please provide details / S
1.15 / There are support arrangements in place. Please provide details / M
1.16 / A knowledgebase is provided as part of the system.
If not, please detail how it will integrate with the institution’s own KB. / S
1.17 / Please provide a comparison with our holdings. / -
1.18 / The knowledgebase will be updated regularly and the procedure for applying the updates will be straightforward. Please provide details / M
1.19 / We can create records for resources which are not in your knowledge base / M
1.20 / Data can be batch loaded from spreadsheets / ONIX / XML / S
1.21 / The system alerts users to tasks that need to be completed. Please describe how this is achieved / M
1.22 / The system systematically alerts the next in line of the next task to be completed / S
1.23 / We can add & remove or customise fields to suit our requirements / C
1.24 / Problems such as downtime can be tracked in an incident log.
Please detail how this information is collected and stored in the system / M
1.25 / The system is easy and intuitive to navigate Please provide a demo site/screenshots / M
2. / Acquisitions
Trials
2.1 / The system will notify us when the trial is available/due to expire / S
2.2 / We can record opinions/notes on trials including reasons to/not to order / S
2.3 / We can create provisional records for trials / C
2.4 / The trial record will show associated costs, licence information, access method and dates / M
2.5 / The transition of the record from trial to purchase is managed efficiently. Please give details / M
Ordering
2.6 / The system records restrictions on cancellation/renewal etc / M
2.7 / The ERM has a list of suppliers. If not, please detail how a list can be imported. / C
2.8 / We can add to/amend the list of suppliers / M
2.9 / The system brings in supplier details from an LMS / M
2.10 / Contact details for suppliers can be stored.
Sales and technical contacts can be kept separately / M
2.11 / There a field to record requester information including e-mail/contact details / W
2.12 / We can record details of which department /faculty/tutor has an interest in the resource / S
2.13 / The system can send alerts to requester/s / W
2.14 / The record shows associated costs, licence information, access method and dates etc.
Please list information shown with screen shot / M
2.15 / All financial records can be stored in the systems - financial records can be imported from and exported to the LMS. Please provide details / M
2.16 / The system is able to track orders and send chasers etc. / M
2.17 / Order status changes and updates are recorded / M
2.18 / There is an audit trail of actions on the record / S
2.19 / The system can check changes to titles, publishers etc.
Information on previous titles can be kept
These changes can be made in systems that we have.
Alerts can be sent re: updates that need to be made to Talis/LASU etc. / M
2.20 / The system will manage print and electronic combined subscriptions. Please give details / M
2.21 / The ERM can identify when a resource is listed on a reading list / W
2.22 / E-mails for consultation can be sent to librarians.
Additional information can be added to this prior to consultation e.g. quotes etc. / W
Renewals
2.23 / There is an option to input renewal dates and set up alerts for 3 months (eg) before renewal date / M
2.24 / The ERM automatically updates renewal dates after renewal. / W
2.25 / The system records whether a renewal is automatic or explicit / S
2.26 / The system records the notice period for renewal / M
2.27 / The system records reasons for renewal or links to written evaluations / S
2.28 / Price increases can be recorded / S
2.29 / The system can record information on deals / packages / individual titles / M
2.30 / We can record which deals are time related, how long we are committed to a resource etc. / M
2.31 / The system can be used to alert publishers to loss of access to resources.
Is this available down to article level? / W
Cancellation
2.32 / The system records whether termination during contract period is allowed – conditions/notice period etc / M
2.33 / The system records cancellation dates / M
2.34 / The system records reasons for cancellation or links to evaluations / S
2.35 / There is functionality to record and manage any permanent/perpetual access after
a.  a. a trigger event
b.  b. a cancellation
c.  including where the access is from i.e. Publisher; Lockss/Portico etc / M
Payment Tracking
2.36 / The system takes into consideration pro-rata payments, credit notes etc to work out expected costs / M
2.37 / The system provides budget information / M
2.38 / The system is able to calculate percentage increases etc. Please describe how this is done / S
2.39 / The system deals with transactions in different currencies. Please describe how this is done / S
3. / Licences
3.1 / The system makes licences viewable to users. Please describe how this is done / S
3.2 / Access is provided to the licence. Please explain how this is achieved e.g. scanned licences uploaded to the system / M
3.3 / Licences are linked to individual resources. / M
3.4 / It is possible, from a licence view, to see all the linked resources
3.5 / Key points of the licence can be ‘picked out’ or highlighted
Eg. Number of concurrent users; Username/password / S
3.6 / These key points can be specified/customised by us / C
3.7 / Key points about the licence can be displayed in a visual format, that is easy to share / S
3.8 / The licence information can be made available to end users Please detail how this is achieved e.g. via the link resolver / S
3.9 / The system records whether:
a.  access allowed for off campus users
b.  access allowed for partner colleges / M
3.10 / The system tracks changes in the licence
e.g. Publisher changing licence details
Change of publisher therefore new licence / S
3.11 / The system is compatible with, and can share licence information with, journal supplier databases.
e.g. SwetsWise (e-journals) / M
4. / Access
4.1 / The system records whether a resource uses Athens; Shibboleth; IP address; Username & password or other authentication methods / M
4.2 / The system records access restrictions / M
4.3 / The system notifies requesters when we have access / W
4.4 / The system records different categories of user/different levels of access / M
5. / Statistics
5.1 / The system collects usage statistics from suppliers via SUSHI. If not, please detail how they are collected / M
5.2 / It is possible to manually enter usage statistics for resources / M
5.3 / A service is provided to load data from non-SUSHI vendors on our behalf / S
5.6 / The system can import usage data via ONIX, XML, CSV / M
5.4 / Usage statistics are presented in a range of formats. Please provide details/screenshots / S
5.5 / The system automatically calculates cost per usage. If not please describe how this can be done. / S
5.7 / If we do not use your link resolver and other front end interfaces, we are still able to collect usage statistics / M
6 / Reports
6.1 / It is possible to report on the workflow i.e. to see where resources are in the process / C
6.2 / The Incident log (qv.1.24) can be reported on.
Please give details / M
6.3 / Reports on orders can be produced. Please provide examples. / C
6.4 / Reports on price increases can be produced. Please provide examples / S
6.5 / The system can report on deals / packages / individual titles, including implications for cancellation / M
6.6 / We can report on whether there are any other dependencies e.g. membership to a society in order to receive a resource. Cost implication e.g. increase in price if a subscription is cancelled. / M
6.7 / The system reports on cancellations within certain parameters e.g. a given year / M
6.8 / There is functionality to report on any permanent/perpetual access after
a. a trigger event
b. a cancellation,
including where the access is from i.e. Publisher; Lockss/Portico etc / M
6.9 / Expenditure reports can be produced / M
6.10 / Reports can be made available to academic staff for review / C
6.11 / The system produces trend analysis reports / S
6.12 / Multiple parameters can be added to reports e.g. subject areas, dates etc. / S
6.13 / Reports can be produced on title overlaps between packages / unique access / M
6.14 / The system can report on items not being used e.g. a monthly report on items not being used below a determinable threshold / S
6.15 / The system can report on resources that are due for renewal, within multiple parameters / S