Organization Monkey

Before we even began to look at the available commercial electronic resource management systems, our Team 1: Evaluation identified a list of features that we wanted our ERMS to have. We composed our list and then added to it using CDL’s list.* We then used the objective list when we evaluated existing commercial ERMS options. We marked the category with a 0 if the ERMS didn’t have the feature, with a 1 if the ERMS did have the feature. The ERMS we ultimately selected to buy had a lot of 1s.

Selection and evaluation
Notification/alert lists for events such as technical problem status update, new e-resource added
Selector
Order status
Manages trials of e-resources: start and end dates

Licensing
Support the following relationships:
a.     identify what license agreements are in effect from a given provider
b.     identify what license agreements are applicable to a given resource or set of resources

Record the categories of users that are authorized for access to a given resource
Permitted uses and restrictions
Number of simultaneous users (not on CDL list)
Explicit info about ILL and the permissible formats in which the content may be shared
Contract signed date
Duration of contract
Renewal type (automatic or explicit)
Archival/Ongoing access
Generate reports of archival/perpetual rights
Link to an online version of the license
Contact info: vendor rep, tech support, licensing
License status
Notification/Alert before license expiration date
Generate reports of resources due for renewal within a designated time period

Implementation and access management
Allows us to assign subject headings to the titles held in the ERMS
Dynamic subject list of databases
Identifies if the title is accessible via IP address or password; if password, notes password.
Subscription start date
Alert cataloging of new title

Resource administration and ongoing management
Record administrative url, username, and password, and associated notes
Contact info: vendor rep, tech support
Facility for reporting/tracking problems

Usage data and assessment
Record usage stats URL, username, password, and notes
Statistics on usage
Support SUSHI
Ad hoc reports that are exportable

Acquisitions and business information
Contact info: vendor rep
Price
Payment history
Fund code
Support import/export of payment info in external system
Prompt via e-mail to renew or cancel, based on a timeline we set
Ad hoc reports that are exportable
Identify titles that are part of a publisher package subscription
Distinguishes library-selected titles and aggregated titles

Holdings information
Store holdings info for resources in standard formats that can be exchanged with other bib systems
Archival/Ongoing access at the package and journal level
Print and Electronic Holdings

OpenURL Interoperability
Update title lists and related URLs from vendors that automatically adds and deletes titles as necessary

Reporting and searching requirements
Searching by subject, ISSN, OCLC, or LCCN numbers, title keyword, publisher, or package
Comparing title lists from different vendors to see overlap

System technical requirements
Interoperate with existing ILS
Links to user guides
Customizable user interface
E-Journal List (A-Z list)
provides MARC records
Authentication
System is offered in a hosted environment
Vendor has substantial experience with providing hosted solution
Vendor provides a staging environment where version upgrades can be tested prior to deployment
Number of simultaneous users and
Total number of user accounts
System availability:
Vendor publicizes maintenance windows
Vendor has a way to broadcast information about unexpected service interruptions
Vendor uses a solution to handle hardware failure incidents. What is their acceptable timeframe for resolution?
Data recovery practices:
System provides a data backup solution consistent with a data loss tolerance of 1 day. Preference is for a solution consistent with a data loss tolerance of 4 hours. How often does the service back up the data?  What type of backup do they use: full or incremental?
Backups are retained for 6 months.  How long are the backups retained?
System supports incremental data restoration
Disaster recovery planning:
Vendor has a disaster recovery plan, and is willing to share a version of it
Data security:
System prevents data from being crawled or indexed unless specifically enabled/allowed
System has controls preventing unauthorized access to confidential information
System utilizes data encryption (if hosted, has https as URL leader)
System has controls restricting vendor from accessing confidential information
System maintains logs of user activity (from the back end)
Batch process support:
System includes a mechanism facilitating initial data loading (preferred).
System accommodates batch processes for updating acquisitions financial data.
User support:
Vendor provides a help desk, with generous support hours, and adequate help desk staffing
System includes online documentation
New user training is available
User interface:
Browser-based system interface is preferred:
Must be browser-agnostic (Firefox, Internet Explorer, Safari)
All URLs should be “stateless,” not storing data in requests or sessions
All URLs should be bookmarkable
Staff should be able to work in multiple windows and tabs simultaneously (preferred)
Error messages are written in plain language
System must provide a mechanism for administrative user to identify records in an error state for exception handling. (ex. a record is hung)
Interface complies with web (or client) accessibility guidelines
System response time (mean response time over any 2-minute period, excluding network delays):
Login or logoff – 1 second
Update transactions – 2 seconds
Search – 2 seconds
View a standard report – 30 seconds or less
Report running (including ad hoc reporting) should not impact transaction (add/update/delete) processing.
Termination options:
Data exports. Application allows for the export of data in a standard (non-proprietary) format.
?
* The information used to be housed at http://www.cdlib.org/inside/projects/erms/index.html but is no longer at that URL.

i’ve followed the development of electronic resource management systems (erms) since they first began to be developed. early on it was easy to see how they *should* be designed. in 2004 i wrote an article in which i identified how a dream erms would be composed:

According to many library staff responsible for managing electronic resources, the ultimate or “dream” resource management program would perform the following functions:
1. Notify appropriate staff before licenses expire
2. Integrate with library management system to eliminate double-keying
3. Maintain current/appropriate vendor contact information
4. Track funds used to purchase resources
5. Eliminate the paper shuffling from one office to another
6. Track consortia purchases
7. Update in real time
8. Produce ad hoc reports
— Kennedy, Marie R. 2004. “Dreams of Perfect Programs: Managing the Acquisition of Electronic Resources.” Library Collections, Acquisitions, & Technical Services 28(4): 449-458.

since that article was published there has been tremendous work in developing erms to meet certain standards, and most of them now address the issues i outlined. reporting features still have a long way to go, though.

two years into my position here at loyola marymount university i lead a team to choose our new erms. we’ve selected innovative’s erms and we couldn’t be more pleased. the features i’m most excited about are: the integration with our existing library system, meaning that there is one less silo of data involved in the mgmt of electronic resources; we can push license rights and restrictions to the top level in the catalog, meaning that our users may be informed how they can use the materials; and all the juicy reports that i can pull whenever i want to.

i’ll post more later about how i composed the teams to select and implement the erms and talk through our actual selection process.  for now, just know that we’re excited!  we’ll be implementing the system in less than a month.