| Chapter 3: Workflow Analysis | |
| Elsa K. Anderson | |
|
|
|
| Abstract |
Management of electronic resources depends primarily on how library workflow is arranged. Different elements such as acquisitions processes depend on an efficient workflow setup. Chapter 3 of Library Technology Reports (vol. 50, no. 3) “Electronic Resource Management Systems: A Workflow Approach” covers how to do a workflow analysis to discover issues with current library resource management, using methods such as the DLF report steps and the TERMS outline. Once a workflow analysis is conducted the library can use the results to determine their selection criteria for adding an ERMS. |
Lots of articles have been written about the changes in library resources and how these changes impact the tasks associated with library workflow. Maria Collins described the need as follows: “The increasing complexity of serials work is creating the need for layered processes to maintain materials still received in physical formats in addition to electronic subscriptions. . . . Traditional workflows designed to manage a simpler, more linear print subscription landscape often need to be broken down and re-conceptualized to scale to the increasing volume or critical mass of academic libraries’ online content.”1 Rick Anderson wrote eloquently about the need to design workflows with patron services as the goal and not perfect library work.2
There are multiple case studies and examples from the literature about the transition from print to electronic journals and the need to rethink serials process workflow. As early as 2000, case studies were published showing how library workflow was changing to reflect electronic collections. As Carol Hansen Montgomery and JoAnne L. Sparks commented, “We set out to change the format of the journals from print to electronic, and it quickly became apparent that we were forcing fundamental changes in library operations. Almost no area of the library has been left untouched.”3 At that time, they noted that overall staff requirements were shifting. In 2003, Rick Anderson and Steven D. Zink noted that library requirements were evolving rapidly with electronic journals and that for libraries to “remain relevant and useful,” they needed to go through “a process of reflection.”4 This reflection on workflow at the University of Nevada resulted in eliminating serials check-in and claiming. Similar rethinking of print journal workflow to eliminate low-value tasks and free up resources for electronic resource management is still evident in the most recent literature.5 Identifying new areas of need and analyzing current tasks gives the library a better perspective on what is actually being accomplished.
Analyzing workflow systematically can identify problems that otherwise may go unnoticed but nevertheless create issues for patrons and library staff. It can also identify tasks that do not need to be completed anymore or gaps in communication and staff training. Workflow analyses may also prove an ideal time for the library to engage in true strategic planning for electronic resources. Anna Hulseberg and Sarah Monson realized that libraries were using multiple different strategies to handle the confusion of electronic resources but that many libraries were not actually going through a strategic planning process. They presented a case study on using these strategies to develop a strategic plan.6 Other libraries, such as at Indiana University Bloomington Libraries, have also taken the opportunity to reorganize and think deeply about the future of the library and the technical services department.7
The process of doing a workflow analysis has also been discussed in great detail in the library literature. The DLF ERMI report described sample workflows with full flowchart outlines.8 Other libraries have also described the process of workflow analysis thoroughly. Kristen Blake and Erin Stalberg implemented a process of workflow analysis based on listening and shadowing, clearly indicating that the goal was listening and comprehension, not judgment.9 Communication as a part of workflow analysis is stressed by nearly every article written on the topic.10
The common thread in all of these articles is the suggestion of a few basic steps to a workflow analysis: clarity about the process, clear communication with all library staff, an iterative workflow conversation, and a list of all possible steps within the workflow to make sure that all are accounted for and transitions are clear. Ideally, workflow analysis will note problematic situations, such as transition of responsibility for an item between people or departments. Other trouble spots are situations where multiple tasks need to be completed simultaneously, such as license negotiation and running a faculty trial for feedback, or points where the process or documentation breaks down. Many of the problems that workflow analysis can identify are communication issues.
Some libraries preferred to manage workflow analysis in terms of what is similar to, and what has changed from, print serials workflow, hoping to minimize the amount of stress and change for library staff.11 Others found that instead of focusing on the change from print to electronic, the important question was purchased versus subscribed resources.12 Yet other libraries decided that this division was arbitrary and focused on combining the former acquisitions and serials departments into one unit to put the emphasis on patron experience.13 Librarians from Duke University described approaching workflow analysis by dividing each process into smaller units to be analyzed since the workflow in their large library was too complicated to represent every step in the workflow process all in one piece.14 Department procedure documents may be a helpful tool in analysis if they are available and up to date. But even if these documents exist and are recent, it is also necessary to analyze individual procedures within the context of the overall workflow of the department and the entire library.
The DLF ERMI report carefully details workflow. The report includes items such as license negotiation or invoice processing, which may consist of a smaller workflow process that also should be analyzed. The DLF ERMI report was designed to provide a framework for libraries to use when trying to do their own workflow analysis. The report divides workflow into four pieces: product consideration and trial, which leads to a decision moving to the negotiation phase, including negotiation on licenses, technical requirements, and business elements. The third phase is implementation, and the final is product maintenance and review.15 The DLF ERMI report also analyzes larger workflows in terms of the smaller, related workflow processes that make the overall worlflow.16
DLF ERMI Report
A new system of conceptualizing the pieces involved in electronic resources has been proposed recently, called the Techniques for Electronic Resource Management (TERMS) project. The TERMS project takes its start from Oliver Pesch’s life cycle of electronic resources.17 Pesch divided the process of managing resources into these broad categories: Acquire, Provide Access, Administer, Support, Evaluate, and Renew, representing a cyclical process so that each step must be performed regularly for every resource involved.
Jill Emery and Graham Stone took the TERMS project–defined elements as a starting point for their own mapping of resource management, but changed the life cycle elements to Investigate, Acquire, Implement, Evaluate, Review, and Cancel/Replace.18 The primary goal of these projects and descriptions is to review and suggest workflow, and a wiki is available as a resource for other librarians.19 The TERMS project is an extremely detailed look at every phase in the life of an electronic resource and an attempt to take a truly broad-based, comprehensive look at the steps and requirements for managing all kinds of electronic resources.
TERMS Report
www.alatechsource.org/taxonomy/term/106/techniques-for-electronic-resource-management-text
TERMS Wiki
In addition to using ordinary communication tools such as e-mail, it can be helpful to have systems to manage and track particular elements of workflow. Such tracking mechanisms provide another service by creating a record of actions so that it is easy to refer back. Other popular tools not specifically designed for workflow management are nevertheless helpful. These include tools such as wikis, blogs, spreadsheets, and homegrown databases, as well as workflow and project management style software such as Microsoft SharePoint and Basecamp. Adam Murray wrote in 2008 about using only free tools like blogs, spreadsheets, wikis, and Google Docs to substitute for an expensive ERMS.20 The University of Nevada singled out e-books as requiring particularly complex and intensive management, involving multiple departments and skill sets and complex overlapping responsibility. It divided e-books workflow into four sections—assessment/acquisitions, access, maintenance/troubleshooting, and end of life—then used the SharePoint software already in place to track the steps comprising each element.21 Robin Featherstone wrote a review of Basecamp focusing on its utility as a project management tool but noted that it helped to improve communication and centralize documents, indicating that it might also be adaptable as a workflow management tool.22
One of the major benefits of ERMSs as advertised now is that they promise to streamline and manage workflow within the library. Many ERMSs and most of the library service platforms available provide functionality for purchasing books and e-books directly within the system, streamlining the purchase and cataloging process. It is important to ask about flexibility of workflows within an ERMS before selecting. Eric Harnett, Apryl Price, Jane Smith, and Michael Barrett, librarians from Texas A&M University, published a case study describing an implementation experience where the library attempted to implement an ERMS that had a defined workflow that did not work for the library and wasn’t flexible enough to be adapted.23 ERMSs are offering workflow management tools such as checklists, alerts, and customizable permissions, but the ability to customize workflow is still extremely important.
Across the literature, in the white papers and recommendations from software vendors, and in the libraries interviewed for this report, a few common requirements for a successful implementation appear. All libraries reporting that their ERM system implementation was a success and that they are satisfied with the product describe an intensive process of workflow analysis and study before choosing a software system or beginning to implement. Libraries in interviews report that doing workflow analysis without the intent of implementing an ERMS also indicated a higher level of satisfaction with their workflow in general and more confidence in their ability to handle electronic resources.
Once an analysis is completed, the library will have a better ability to handle electronic resources and a clearer idea of problem areas that need to be addressed. Under those circumstances, the library is well positioned to begin the process of evaluating ERMSs and prioritizing requirements, which in turn leads to a greater chance of a successful implementation and a good final result. In interviews, multiple libraries credit their successful implementations to careful selection of the required software, based on a workflow analysis to solve actual problems and inefficiencies, without getting swept up in additional functionality or an attractive system.
When selecting an ERMS, it is important to keep the results of the workflow analysis in mind. Whatever software is selected either should fit into the existing workflow, to make it easier, or should solve a problem in workflow management, such as communication and centralization of information. For this reason, before the selection process begins, the library needs to complete its workflow analysis, not only writing down what happens in the library but also taking the time to analyze it. Before moving to selection, the library needs to have a clear idea of which tasks are time-consuming but low priority, where print functionality can be cut back or eliminated, and where and how to transfer electronic responsibilities. This is a tricky balance to strike. The library must have an idea of what problems to solve and what it would like to keep of its current workflow, must maintain enough of the workflow to continue services until the selection and implementation process is complete, and must remain flexible enough that the changes and rethinking that inevitably come with a new software implementation will not be too difficult. Generally, the library should strive to identify an ideal, large-picture workflow, prioritize the importance of individual elements of that workflow, and then use those to create its selection criteria before beginning serious research on ERMSs.
Once a library has gone through a workflow analysis and developed a good idea of what it needs, the most difficult task remains: how to know which system would work best for its specific library environment. If there are many options for software and each software provider has a different strength and focus, then what should any particular library choose? In an ideal world, each library software system would completely fill any library’s needs for ERM. Any system would be able to interact with any other system without work-arounds, and they all would be interoperable with all other library software. In practice, however, these systems have extremely different functionality, and there are large differences in how any particular system might interact with others. For a library to pick the system that will work best for it, the library has to be very clear on what it hopes to gain from the system. Expecting an ERMS to suddenly solve all of a library’s problems will lead only to disappointment and frustration. However, if a library is clear on what it hopes to gain from the system and chooses software accordingly, an ERMS can be extremely helpful and well worth the cost and implementation time. As H. Frank Cervone noted in his column on library software, “The first basic question in the selection process is ‘What problem are we trying to solve?’”24 He recommended starting with a problem statement and a clear idea of what the project under consideration will accomplish and using these statements to create selection criteria.
One library included in the interviews for this report attributed its satisfaction with their ERMS to the process for selection. Before the library selected the software, staff went through and created a very clear list of what they were hoping to accomplish with the software implementation. When they had this basic list, they prioritized it very carefully. The next step was doing a significant amount of research, not only talking to the vendor but also going to area user groups, speaking to the staff of other libraries that use the product, and making sure that the systems evaluated could fulfill the highest priority needs. Because of this process, library staff were able to choose a system that worked the best for their library. They were extremely satisfied with the chosen product. Conversely, libraries that did not recommend their ERMS software or that said they were less happy with it generally said they had decided on the product for other reasons, such as financial constraints or a desire to stay completely with one software vendor.
It is important to think very carefully about the criteria used for selecting an ERMS. Wanting to expand vendor options to include the ERMS is a reasonable strategy, as will be discussed later in this chapter, and has multiple pros and cons. But the experience of the library mentioned above indicates the importance of deciding on priorities and making sure that priorities align with solving the problems identified in the workflow analysis. This is why the workflow analysis is so important—to discover what the priorities are before beginning to evaluate products so that the library does not get sidetracked in the process.
The common factor for libraries that are satisfied with their ERMS seems to be clear expectations defined before beginning the project and developing selection criteria based on the needs of the library. Among the librarians interviewed, those that mentioned a clear plan, evaluation of needs and workflow, and software selection based on the plan generally reported being very satisfied with their ERMS. On the other hand, libraries that selected and implemented an ERMS based on other criteria seemed the most dissatisfied.
Once the major problems with workflow have been identified, the library can begin work on deciding what the solutions should be. If the problem is difficulty tracking and creating budget reports, it is important to find systems with extremely robust financial management and reports and to consider whether the library needs information such as cost-per-use reports for good management of resources. If the biggest problem is broken links out of the catalog into electronic serials, perhaps the most important piece is a frequently updated knowledge base and inexpensive, high-quality serials MARC records. The highest priority for the library could be one of many different elements of ERM: tracking purchasing history, simplifying interlibrary loan permissions, managing licenses, having more systems interoperability, managing large journal packages, producing better financial reports, or many others. Very few systems are good in all of these areas, but most will do several very well, and this can be a major help when trying to decide on ERMSs. Jared Howland and Thomas Wright expressed this succinctly: “The product chosen should be based on the best possible match of needed features to available features. The limiting factor in a purchase decision, as always, is the price of the product and the available budget.”25 They also mentioned that in retrospect, their library would have placed greater emphasis on accuracy of the knowledge base and integration with the ILS.
There are also other, simpler questions that may affect a library’s decision. If the library has a policy of not allowing vendor-hosted software because of privacy or data security concerns, it may be able to look only at locally hosted and installed systems. If, on the other hand, the library does not have the money, the staff, or the resources to host its own servers and maintain them, it may need to stick with vendor-hosted and cloud software solutions. If a library has no budget at all to add software, there are several very good open-source options, but again, it is important to be clear on whether the library has space on a server or if the library ERMS needs to simply live in a small, shared network space. An open-source solution might also work best if the library has a robust technical support staff or at least multiple tech-savvy people able to support and troubleshoot the system.
Once a library is clear on the most important criteria, it can examine the available software options to see what will be most helpful. This will prevent disappointment and allow simultaneous implementation of other systems or workflows to cover all necessary functionality. For example, a library that needs good statistics plus budget management might need to look at add-on COUNTER products at the same time as it selects an ERMS, or at systems that incorporate COUNTER statistics with budget tracking. Or in another example, a library very happy with its ILS and looking to expand its ERM capabilities might want to include setting up a purchasing agreement for electronic resource package records with a vendor in order to simplify the task of getting all resources into, and updated within, the ILS in a timely manner.
General criteria to keep in mind:
- Timeframe and resources. Resources will determine how fast a project can move, which will determine the overall scope of the project. For example, incorporating a stand-alone ERMS as an add-on for an ILS and link resolver system is a much simpler project than migrating all library systems to a library service platform. If there are not enough resources to do a large project such as migrating the ILS, then the project needs to be reframed with a smaller scope more focused on resource management. Resources include money for software licensing and servers, but also include staff time, training budget, time when the library is able to do a large product, the ability to slow ordinary work for a period of time to get a project completed, and IT staff and support for the technical side of the project. Bear in mind that all staff who will need to use the new system or whose workflow is affected will need training and support during the transition.
- Library constraints. Constraints will include budget and IT requirements and limitations including the ability to host servers, staff to administer and support hardware and software, security restrictions on vendor-hosted software, and support and resources for open-access software.
- Priorities. Identify the most important problems to solve and concentrate evaluation on products most focused on those particular issues.
Identifying and working from larger constraints will help streamline moving to a selection process by immediately eliminating some possible software solutions that are inappropriate for a particular library. Additionally, the more clearly problem areas are identified ahead of time, the easier it will be to tell if a particular software product will address those areas.
The best system for a particular library will depend not only on what problem the library is hoping to solve, but also on what additional systems the library is hoping to replace. If a library wants to keep its ILS, a system designed for electronic resources only such as the Serials Solutions or EBSCO products may be the best. If a library is not happy with its ILS, it may want to consider a new ILS more integrated into ERM, such as Innovative Interfaces’s Millennium with the ERM module. Or a library might want to consider moving to one of the library services platforms: Alma from Ex Libris, OCLC’s WorldShare, Intota from Serials Solutions, or Sierra from Innovative Interfaces. The library will want to consider its long-term plans for software migrations and whether it is planning to upgrade, develop. or sunset related homegrown software.
Nat Gustafson-Sundell, in his case study of ERMS implementation, noted in his literature review that “it seems clear that local conditions will largely determine whether any given ERMS implementation will succeed or fail.”26 Northwestern University Library performed an extensive selection process with a thorough literature review, and the case study is well worth reading as an example of the selection process.
Here are some general selection process steps for libraries considering implementing an ERMS:
- Examine the current library system, including particularly workflow and the ways electronic resources affect the patron experience. This examination needs to go beyond the technical services department to the entire library to be really effective. Identify problems that need to be solved and areas that work well and can be expanded.
- Decide on the scope of the project. Is the library interested in adding a small ancillary system to solve a specific problem or track a process? Is the library facing an end-of-life ILS system or looking to add a discovery layer? The scope of the project will influence every step of selection and implementation.
- Form a group or designate the person responsible for data gathering and selection.
- Gather information on what systems will fit the need and the scope of the project. This step may start with visiting vendor websites, reaching out to vendors for demonstrations and quotes, searching library literature to read recent library experiences, and reaching out to other libraries to see what their experiences have been with a particular system. Gathering information and watching demonstrations will probably be an iterative process, with several rounds of information and questions. The clearer the library is on what it is looking for, the more specific and helpful the information-gathering process will be because the questions can be more focused and specific. Using a spreadsheet or questionnaire to evaluate products may be helpful at this point.
- Use the information gathered and input from library staff members to make a decision as to which solution will fit the library best.
- Make arrangements to move ahead with the implementation process. Make sure, if working with commercial vendors, that they have committed to helping with implementation and training and that the library is clear on the schedule and extent of this help. If a library is implementing a smaller or open-source system, an implementation plan detailing order of events, responsibility outline, timeline, and overall estimate of resources may be extremely helpful.
It may be tempting for a library to simply add on additional products from a vendor that it is already satisfied with, perhaps its link resolver or ILS vendor. This strategy does have several advantages. It may eliminate some of the common interoperability problems with other software, and library staff may already be familiar with the interface, thus facilitating a shorter learning curve. Vendors may be able to devote more resources to a library with a large suite of products, and the vendor technical support and implementation support personnel can focus on servicing their own product instead of trying to resolve difficult interoperability questions. This is definitely an option to consider, but it is important to be aware of library requirements to make sure that this course of action is really the best in a particular situation.
Familiarity with vendor products as well as staff comfort with the software interface are important benefits. Also important is the already existing vendor relationship, the library’s knowledge of the vendor’s support level and attitude, and its relationship with individual representatives. Beyond this, each vendor brings a particular understanding of library resources, one that is implicit in its software and its approach. When a library already uses software from a particular vendor, the library will already understand that vendor’s approach and descriptions. This will speed up the learning curve for the new software and make implementation easier and faster, as well as speeding up comprehension of the software and mapping library workflow into the software.
However, picking the default software may not solve the most pressing problems a library has. Implementing software that does not solve the major issue identified by the library will ultimately create more work for library staff, no matter how much easier it may be to implement. This report was actually inspired by a similar story: a library added an ERMS because it liked all the vendor’s other products. The library tried to implement it without doing a workflow analysis or identifying trouble areas and ended up with redundant systems and a failed implementation. A year and a half later, after a detailed look at workflow, the same ERMS was implemented successfully and became a crucial piece of the resource management process. The ERMS did become more sophisticated and added functionality during the one-and-one-half years between the initial and the final, successful implementation, but this was not the major difference. The main reason for the initial failure and the later success was the time spent defining problems with workflow and communication in the library, then looking for technological solutions. When the unique problem the ERMS could solve was identified—namely, collecting administration information and statistics—then the implementation went quickly and the ERMS became uniquely useful, allowing the library to look at decommissioning older systems and streamlining workflow as well as reducing dependence on old paper files.
The situation described above is common and exemplifies why the workflow analysis is so important. Without a clear understanding of library needs, it isn’t possible to adequately weigh the pros and cons of a particular solution. The benefits of well-understood software and a company that the library knows and likes are significant, but not sufficient to manage all library resources. It is entirely possible that even if a vendor solution meets only two of a library’s most important three requirements, it may still be the best system for that library’s needs. If this is the case, then after doing the workflow analysis and making the selection, the library would already be aware of existing gaps and, while proceeding with the implementation of vendor software, it could also make plans to fill the one unmet need with other software or with a workflow work-around.
Notes
| 1. | Collins, Maria. “Evolving Workflows: Knowing When to Hold’em, Knowing When to Fold’em,”Serials Librarian 2009;57(3):262.doi: 10.1080/03615260902877050 |
| 2. | Anderson, Rick. “It’s Not about the Workflow: Patron-Centered Practices for 21st-Century Serialists,”Serials Librarian 2007;51(3–4):189–199.doi: 10.1300/J123v51n03 |
| 3. | Montgomery, Carol Hansen; Sparks, JoAnne L.. “The Transition to an Electronic Journal Collection: Managing the Organizational Changes,”Serials Review October–December 2000;26(3):5. |
| 4. | Anderson, Rick; Zink, Steven D.. “Implementing the Unthinkable: The Demise of Periodical Check-in at the University of Nevada,”. Library Collections, Acquisitions, and Technical Services. 2003. 62, doi: 10.1016/S1464-9055(02)00309-3 |
| 5. | Tumlin, Markel, et al. . “Is Check-in Checking Out?” Serials Review 29, no. 3 (Autumn 2003): 224–229; Carol Ann Borchert, “To Check In or Not to Check In? That Is the Question!” Serials Review 33, no. 4 (December 2007): 238–243; Karen Hunter, “The End of Print Journals: (In)Frequently Asked Questions,” Journal of Library Administration 46, no. 2 (2007): 119–132; Roger C. Schonfeld, “Getting from Here to There, Safely: Library Strategic Planning for the Transition away from Print Journals,” Serials Librarian 52, no. 1–2(2007): 183–189; Martin Zimerman, “Periodicals: Print or Electronic?” New Library World 111, no. 9/10 (2010): 426–433 |
| 6. | Hulseberg, Anna; Monson, Sarah. “Strategic Planning for Electronic Resources Management: A Case Study at Gustavus Adolphus College,”; Journal of Electronic Resources Librarianship. 2009. p. 164doi: 10.1080/19411260903039637 |
| 7. | Lynda Fuller Clendenning. Duggan, Lori; Smith, Kelly. “Navigating a Course for Serials Staffing into the New Millennium,”Serials Librarian 2010;58(1–4):224–231.doi: 10.1080/03615261003625893 |
| 8. | Jewell, Timothy D.., et al. . Electronic Resource Management: Report of the DLF ERM Initiative. Washington, DC: Digital Library Federation; 2004. |
| 9. | Blake, Kristen; Stalberg, Erin. “Me and My Shadow: Observation, Documentation, and Analysis of Serials and Electronic Resources Workflow,”Serials Review December 2009;35(4):242–252.doi: 10.1016/j.serrev.2009.08.018 |
| 10. | Ohler, Lila A.. , . “The Keys to Successful Change Management for Serials,” Serials Librarian 51, no. 1 (2006): 37–72; Schonfeld, “Getting from Here to There”; Collins, “Evolving Workflows”; Celeste Feather, “Electronic Resources Communications Management: A Strategy for Success,” Library Resources & Technical Services 51, no. 3 (July 2007): 204–212; Janet Chisman, Greg Matthews, and Chris Brady, “Electronic Resource Management,” Serials Librarian 52, no. 3–4(2007): 297–303; Adam Murray, “Electronic Resource Management 2.0: Using Web 2.0 Technologies as Cost-Effective Alternatives to an Electronic Resource Management System,” Journal of Electronic Resources Librarianship 20, no. 3 (2008): 156–168 |
| 11. | Dollar, Daniel M.., et al. “Realizing What’s Essential: A Case Study on Integrating Electronic Journal Management into a Print-Centric Technical Services Department,”Journal of the Medical Library Association April 2007;95(2):147–155.doi: 10.3163/1536-5050.95.2.147 |
| 12. | Khater, Polly; Appleton, Betsy. “Using a Local Electronic Resource Management System to Manage E-Journals: Can It Get Any Better Than This?”; Serials Librarian. 2010. p. 250.-256.doi: 10.1080/03615261003626016 |
| 13. | Zhang, Xiaoyin; Haslam, Michaelyn. “Movement toward a Predominantly Electronic Journal Collection,”; Library Hi Tech. 2005. p. 82.-89.doi: 10.1108/07378830510586720 |
| 14. | Dowdy, Beverly; Raeford, Rosalyn. “Electronic Resources Workflow Analysis and Process Improvement.”. In Electronic Resources & Libraries Conference. Austin, Texas, 2012 |
| 15. | Jewell, Timothy D.., et al. . Electronic Resource Management: Report of the DLF ERM Initiative. Washington, DC: Digital Library Federation; 2004. section 4.3.2 and appendix B |
| 16. | Ibid |
| 17. | Pesch, Oliver. “Library Standards and E-Resource Management: A Survey of Current Initiatives and Standards Efforts,”Serials Librarian 2008;55(3):482.doi: 10.1080/03615260802059965 |
| 18. | Emery, Jill; Stone, Graham. “Techniques for Electronic Resource Management,”Library Technology Reports February 2013;49(2):6. |
| 19. | Ibid., 6, 8 |
| 20. | Murray, Adam. “Electronic Resource Management 2.0: using Web 2.0 Technologies as Cost-Effective Alternatives to an Electronic Resource Management System,”Journal of Electronic Resources Librarianship 2008;20(3):156–168.doi: 10.1080/19411260802412869 |
| 21. | Beisler, Amalia; Kurt, Lisa. “E-Book Workflow from Inquiry to Access: Facing the Challenges to Implementing E-Book Access at the University of Nevada, Reno,”Collaborative Librarianship 2012;4(3):103. |
| 22. | Featherstone, Robin. “Basecamp,”Journal of the Medical Library Association January 2009;97(1):67.doi: 10.3163/1536-5050.97.1.019 |
| 23. | Hartnett, Eric, et al. “Opening a Can of wERMS: Texas A&M University’s Experiences in Implementing Two Electronic Resource Management Systems,”Journal of Electronic Resources Librarianship 2010;22(1–2):18–27.doi: 10.1080/1941126x.2010.486721 |
| 24. | Frank Cervone H.. “Some Considerations When Selecting Digital Library Software,”OCLC Systems and Services 2006;22(2):107.doi: 10.1108/10650750610663987 |
| 25. | Howland, Jared; Wright, Thomas. “Implementing an Electronic Resource Management System: Brigham Young University’s Experience,”Library Hi Tech News 2006;23(7):28–31. |
| 26. | Gustafson-Sundell, Nat. “Think Locally: A Prudent Approach to Electronic Resource Management Systems,”Journal of Electronic Resources Librarianship 2011;23(2):127.doi: 10.1080/1941126x.2011.576955 |
Article Categories:
|
|
Refbacks
- There are currently no refbacks.
Published by ALA TechSource, an imprint of the American Library Association.
Copyright Statement | ALA Privacy Policy