Report of the DLF Electronic Resource Management Initiative ...

More documents

Recommendations

Info

Staff Requirements STAFF INTERFACE Report of the DLF Electronic Resource Management Initiative Appendix A: Functional Requirements for Electronic Resource Management An electronic resource management system requires a staff interface that enables library staff to efficiently carry out the work described in the sections that follow. The interface should be organized into views that are optimized for particular areas of staff activity or interest such as resource acquisition, troubleshooting, license administration, or administration and statistics. Details of appropriate interface design are not addressed in these requirements, but rather left to the art and discretion of system developers. Through this interface, staff should be able to: 19. Search, browse, and retrieve records by attributes unique to electronic resources such as license, vendor, interface, record status, licensed site, consortium, and library selector or other local contact individual; 20. View the full range of information appropriate to the staff member's security profile and functional role; 21. To the extent possible, link to other relevant information stored in library management systems, portals, or related systems; and 22. View records that are hidden from the public SELECTION AND EVALUATION PROCESS During the selection and evaluation process, it is typically necessary for a decentralized group of individuals to coordinate a complex and iterative series of steps. The ERMS should provide support for recording actions at each of these steps and have the capability to perform specified actions upon completion of a given task and to send alerts when actions that have been anticipated do not occur. A typical selection and evaluation process might involve the following steps and require the following reminders and notifications, all built from stored action dates and locallydefinable status fields: • Build request record for trial; • Flag resource as trial; • Notify interested parties that trial is live and provide the access instructions and expiration date [triggered by trial start date and email address(es) input into request record]; • Allow staff (and, optionally, users) to access the trial via stored URL; • Send reminder to those notified of a trial that expiration date is near [triggered by trial end date and email address(es) input into request record]; • Record opinions of key players and final purchase decision, allowing for both central or local input of opinions and funding commitments into notes fields in request record; 11/14/12 p. 6
Report of the DLF Electronic Resource Management Initiative Appendix A: Functional Requirements for Electronic Resource Management • Prompt licensing/acquisitions contact to report purchase decision [triggered by decision date input into request record]. Most common options: approved, rejected, or on hold; • For resources that are approved for purchase, additional statuses and actions would be required, including: • Notify licensing contact to obtain and negotiate license, and remind this contact if license is not completed by a given deadline [triggered by stored licensing contact, status of ‘approved’, and deadline input at time of approval]; • Notify access contact if status has not changed to “live” by deadline [triggered by inputting likely access date into system at time of approval]; • Notify cataloging and selector/product sponsor as well as other interested parties when access is available [triggered, e.g. by changing status to “live” and by stored email address(es) related to this purchase] The companion Workflow Flowchart for Electronic Resource Management provides a detailed diagrammatic view of workflow decision and action points. To support these processes, it should be possible to: 23. Create provisional records for resources that may or may not be permanently acquired, and track the selection and evaluation process through acquisition or rejection. 24. Assign locally-definable status fields to request records and associate particular actions with those statuses. Examples might include: “new request,” “on trial,” “trial expired/decision pending,” “approved,” “rejected,” “on hold,” etc. 25. Assign locally-definable fields to request records for license routing and status, and associate particular actions with those fields. Site should be able to, for example, define a list of individuals from whom sign-off is required, send reminders to license reviewers, and record approval or rejection status, with notes. 26. Assign multiple local contact individuals and site-defined roles to both request records and permanent resource records. 27. Send email notifications to individuals designated as local or licensing contacts. 28. .Make trial resources available in a secure manner through the library’s resource tool of choice to authorized users (if wanted) and/or to staff, but not to unauthorized persons 28.1. Store trial URIs and passwords and make these securely available, securely if necessary 28.2. Flag items unambiguously as trial resources, with associated public and staff notes 28.3. Record a trial expiration date and, optionally, send an alert to designated recipients N days prior to trial expiration 11/14/12 p. 7
Page 1 and 2: Report of the DLF Electronic Resour
Page 5: Report of the DLF Electronic Resour
Page 13: Report of the DLF Electronic Resour

Report of the DLF Electronic Resource Management Initiative ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?