[I missed the first talk due to a slightly longer lunch than had been planned.]
Better Linking by Our Bootstraps
Speaker: Aron Wolf, ProQuest
He is a librarian trained as a cataloger.
Error reports are important, because for each one, there were probably ten instances not reported. Report early and report often.
Include the original query for the OpenURL in order to reproduce it. If you have the time, play around with the string data and see if you can “fix” it yourself and report that.
There are a lot of factors into how long it will take to fix whatever is causing the OpenURL error. They don’t want to raise false expectations by giving a date and time.
Once an error has been reported, it enters a triage system. If it has a broader impact, it will be prioritized higher. Then it’s assigned to someone to fix.
Trouble Ticket Systems: Help or Hindrance?
Speaker: Margaret Hogarth, The Claremont Colleges Library
We should be polite and helpful. Human.
Detail the issue as specifically as possible, with steps, equipment, screen shots, etc. Include account number or other identifier.
Vendors need to identify themselves in responses. They also need to include the issue in responses, particularly when the message trail gets long. Customers need to keep track of the trouble tickets they have submitted.
Respond promptly, even if it will take longer to resolve. Mine the trouble ticket data to create FAQ, known issues, etc. and add meaningful metadata.
Email is good for tracking the history. Online forms should have an email sent with the ticket detail and number. Some vendors hide their support email address, which is annoying.
If vendors require authentication to submit a ticket, provide examples of what information they are looking for.
Vendors should ask their most frequent support users for feedback on what would make their sites more useful.
Multiple tech supports make it challenging for reporting issues to large companies.
Jing screen casting is helpful for showing how to reproduce the problem, particularly when you can’t attach a screenshot or cast, since it provides a URL.
All of this is useful for your internal support ticketing systems, too.
Goal is to be more of a dialogue than a monologue.
In 2011, they were a traditional acquisitions and cataloging department. They had 18.1 FTE in technical services, with 8 acquisitions people working on both print and electronic, and 5 in cataloging. It felt very fragmented.
They were getting more eresources but no new staff. Less print, but staff weren’t interchangeable. The hybrid positions weren’t working well, and print was still seen as a priority by some of the staff. They could see the backlogs and made it seem like they had to deal with them first.
They hired consultants and decided to create two format-based teams: tangible formats and electronic resources. They defined the new positions and asked staff for their preferences, and then assigned staff to one team or the other. The team leads are focused on cataloging side and acquisition side, rather than by format.
To implement this they: oriented and trained staff; created workflow teams for ejournals, ebooks, and databases; talked with staff extensively; tried to be as transparent as possible; and hired another librarian.
They increased the FTE working on eresources, and they could use more, but this is good enough for now.
Some of the challenges include: staff buy-in and morale; communicating who does what to all the points of contact; workflows for orders with dual formats; budget structure (monographs/serials, with some simplification where possible, but still not tangible/electronic); and documentation organization (documenting isn’t a problem — find it is).
The benefits are: staff focusing on a single format; bringing acquisitions and cataloging together (better communication between functions); easier cross-training opportunities; workflows streamlined easier; and ease in planning and priorities.
She teaches a course on ERM, which is why she’s doing this research. She initially planned to do a comprehensive job ad analysis and then look at LIS syllabi to see if we were meeting the needs. Then she found Sarah Sutton’s 2011 dissertation that did most of this already. So, she changed her strategy to evaluate the competencies once they were adopted.
She interviewed ER librarians about their work, their institution’s workflow, and their perspectives on the competencies. She targeted jobs posted to ERIL from 2008-2012 and followed up with the folks who were hired. Of those identified (42), 16 responded to her inquiry.
Most had paraprofessional experience with web design, reference, serials, ILL, and archives. They received their degrees between 1980 and 2012. Most have reference/instruction and collection development/subject liaison responsibilities. Median FTE at their institutions was 13,900.
Their typical day “depends on the time of year,” which affirms the importance of understanding the lifecycle of ERM. Work seems to be most intense at the beginning and end of the semester, which isn’t covered in the lifecycle as explicitly.
Though they had many different roles, there were some commonalities: troubleshooting access and other issues, primary point person for vendor communication, and working closely with subject specialist and systems/IT personnel.
The interview took the Core Competencies and lumped them into four broad areas and didn’t specify the source: technical, analytical, legal, and interpersonal. The participants were asked to rank these.
Least important were the legal competencies, in part because many institutions had legal departments that could make sure that they were signing reasonable licenses, or they were negotiated at the consortial level. They also felt that identifying library-related clauses becomes rote after a short period of time.
Third most important were the technical competencies, in part because it’s all in flux and you’ll have to learn something new tomorrow anyway. It’s more important to be able to learn than what you know right now. Most important skills were website/database design and Excel. A certain degree of technical savvy was important communicating with internal and external technical contacts. Some felt that having a deep knowledge of cataloging as a core competency was off-base, possibly because the metadata department usually handles all formats and ER librarians are typically not involved with that.
Second most important was analytical.
First most important were interpersonal competencies. You need to be able to understand what is happening with so many key contacts, from students to faculty to colleagues to vendors. Good relationships with vendors can influence product development and getting good customer service. Collaboration is huge.
Moving forward, she plans to continue the analysis of the open-ended questions and compare with the Core Competencies. She will evaluate the MLIS program curricular pathways and syllabi for ERM courses to get at the unique competencies that are not covered by ALA requirements.
Really admires the comprehensiveness of the NASIG Core Competencies.
Question about the dearth of ERM courses in our LIS programs. Speaker noted she is doing this to promote ERM education because everyone coming out of LIS should know something of this, like we all learned cataloging and reference.
Is 16 a good sample? Yes, for qualitative research. Each interview was 1.5 hrs, and takes about 6hrs to transcribe. Her colleagues thought it was a great sample, too. If she did more, it would be a questionnaire based on this qualitative research to get a broader response.
What were the reasons people were enthusiastic about Excel? A lot to do with not much luck with implementing ERMS and using it to manage their administrative data. Title analysis, generating stats, use reports, etc. “I try to develop a new Excel technique every week.”
Question for us: Is there a strong distinction between digital librarianship and licensed content librarianship? Response: Yes!
Question for us: relationship between ERM and cataloging. Response: It’s good for us to know some to communicate (more than say, a reference librarian), but we don’t do the work.
Respondents said, for the most part, that no one else in their library could do their job if they got hit by a bus. The main reasons being that no one else had the comprehensive vision of what goes on with managing ERM.
Used TERMS as a framework for developing an eresources team and a course at University of Wisconsin.
How are we going to systematically ensure that our eresources knowledge evolves and continues?
75% of UConn’s budget is for e-content. The human resources was 3.25 FTE when she arrived, but now they are at 5.65 FTE. The only other unit smaller is the digital scholarship and data curation team created a year ago.
Why does collection development for non-ERM staff exist as a term for non-electronic monograph acquisitions? In 2014? How do we establish eresources teams and teach this to staff?
TERMS helps build a framework for discussion among her students and her work team. The Core Competencies was used for class reading and discussions with her team, and became a framework for submitting training requests. TERMS has been a lighthouse for them, and they’ve continued to go back to them and review the cyclical process to identify successes and areas for improvements.
Only 19% of the ALA accredited LIS programs cover ERM topics, yet 73% of recent job ads require ERM competencies.
The financial resources are be allocated, what about the human resources to do our work. Eresources positions are not entry-level, and yet the spend in that content is increases. How can we expand/grow the ERM skill-set to more of our staff positions? This is not a new problem. We’ve been talking about this as a profession since 2000 or earlier.
The Core Competencies should be for the entire library, not just the ERM staff.
We need to eliminate the delineation between print and electronic management/acquisitions.
Establish partnerships with LIS programs. Establish paid fellowships that are at least two fiscal years in length. Get support from library administrators for adequate staffing and the time to teach courses, etc.
Good strategies for training staff: Listening to them and knowing what they already know how to do. Making analogies from what you know to what they know. Small chunks at a time.
Are the NASIG Core Competencies a laundry list of the ideal rather than true core competencies that can be expected at the beginning of an ERM career? No. The point is that no one person can do everything ERM. But, these are the things that are needed to manage eresources, regardless of how many people it takes to do it.
Audience member says she had to fail badly with only two staff in order to get the change needed to have a sufficient number of people on her team.
It’s funny how expectations are raised each time they are met. I think about this a lot when I’m working with our ERMS. My first experience with an ERMS was overwhelming and confusing, mostly because I didn’t have the time to really implement it, and it was far more robust than what we needed at the time. The next ERMS I used was simpler, and built off of a system I already knew well. It wasn’t perfect or comprehensive, but it was enough to get going.
Now that I’ve got a few years under my belt with this ERMS, I find myself longing for the next generation tool. Sure, it does this one thing really well, and sometimes even continues to do it well when the coders “enhance” it. But to get more out of it requires a lot of work-arounds, and often those are broken with the “enhancements.” And I’m still porting data from our ILS and massaging it into something our ERMS can ingest properly, often times having to do this manually.
I saw a demo of Ex Libris’ next generation ILS, Alma, a few weeks ago. It’s not perfect, and I could already see how it will require some significant workflow changes. However, the workflow/resource management problems that ERMS have been trying to solve are no longer partitioned off into something other than the “normal” ILS workflows, but rather acknowledged as at least half or more of the workflows that happen within the ILS. That’s what the first gen ERMS tried to do, but as add-on modules with connectors and legacy deadweight. Alma, from what I understand, has been rebuilt from the ground up. That seems to be making a huge difference in performance and integration.
I’m pretty excited about this because it solves two (or more) problems with one product. First, we get a next gen back-end catalog that works with more than just MARC, allowing us to integrate our digital collections metadata in whatever language that may be. Second, we integrate the workflows of all of acquisitions, not just print resources.
I’m also excited about this because I know that the other ILS vendors and ERMS vendors are going to have to step up their game as well. That can’t be bad for libraries and users, right?