The end of eresourcejournal

At the end of the month, I will begin my new job at Norwich University as their Distance Learning Librarian. I am very excited about this position because I’ve wanted to work with distance learning students since the not-so-long-ago days of my own online graduate program. This is my dream job.

And so, eresourcejournal reaches its end. This blog has been more helpful to me than I expected. The process of writing about things that puzzle and frustrate me has been beneficial. First, it makes me think things through. My brain works faster than my fingers, and as I type my mind wanders to another (more appropriate) idea. Had I not taken the time to write about these topics, I may not have come to those more useful conclusions.

In addition, writing is a great memory tool. Writing online with blog software allowed me to easily retrace my steps and remind myself of past discoveries. In some cases, I was able to solve a new problem by looking back at similar situations.

Lastly, blogging connects: the advantage of writing publicly and online is that other people found me. I am grateful for the comments and emails I’ve received from everyone who visits the site or reads the RSS feed. Librarians have been a source of (wonderful) ideas, commiseration, and camaraderie. EBSCO folks have been very generous with their time, emailing me directly about the concerns and ideas I’ve covered in my posts.

Perhaps others will continue to discover these posts and find them useful. Clearly, they’ll be curious about troubleshooting electronic serials problems, as illustrated in this nifty word cloud of all the text at eresourcejournal (made at Wordle.net). I don’t know yet whether I will blog about my new job. As I re-read that sentence, I realize I likely will. I want to remain connected to my community of colleagues. I have been and will continue to follow blogs related to distance learning and distance learning librarianship. I’m sure I’ll have a few things to talk about, too.

Thank you for your visits and keeping me in your feed readers. Most of all, thank you for your comments.

(P.S. It’s a time of transition: Kelly retired one of her blogs this week. Great minds think alike!)

(P.P.S. It seems like a good idea to close the comments on all my old posts. So I’m gonna. I’ll keep this post open, so feel free to leave a message.)

Statistics updated

June’s statistics are now included in the graphs on the statistics page.

I’m reminded again that the troubleshooting tracking sheet doesn’t lend itself to very useful statistics. In tomorrow’s meeting of our serials group (charged with facilitating the merge of our main and medical libraries’ serials departments), we’ll discuss the kinds of data we need to start tracking in order to keep better statistics.

Statistics updated

May’s statistics are now included in my three charts.

It should be a slow couple of months on the troubleshooting front. May-September were quiet months last year. Perhaps I’ll take advantage of that relative quiet to enhance the statistics-gathering process. To do so, I’ll probably collaborate with my serials colleagues to clarify what we should count in our statistics: shouldn’t our own discoveries of problems be included alongside problems uncovered by or on behalf of patrons?

Also, we should decide what information to include in our statistics-tracking, and what kind of information we should derive from the statistics. To start, we should quantify our unresolved troubleshooting problems; the fact that the majority of May’s problems were resolved within one business day becomes less impressive when you can see that the four unresolved problems from that month are three weeks old.

When an email starts a snowball

We (or maybe just I) receive messages from publishers telling us when we have new content available online. I received one last month from Atypon about three Thomas Telford titles. Generally, the announcement is just a heads-up that there are more issues online because more issues have been published.

But I noticed a few problems with this most recent message. I checked each title (and its alternate title formats, such as Proceedings of the…) at the publisher’s site (Atypon), the A-to-Z administrator, and our order records (EBSCONET).

Two titles aren’t listed on the Atypon site so I can’t check for access. I have to ask Atypon why. The third title is, but EBSCO doesn’t have a Publisher’s Site link; I asked them to add a link. Once I find out whether there will be access on Atypon, I’ll ask EBSCO to add records in the Title Wizard.

None of this is a big deal. None of this is challenging. None of this is hard to remember. It’s worth illustrating because it’s typical of how a seemingly simple notification can become a very involved process and result in a lot of work. I think that’s what most of my efforts go towards: a whole bunch of work that comes from an itty bitty notification.

That’s why the troubleshooting statistics aren’t truly indicative of the amount of work involved with problem solving and management. A troubleshooting problem that can be quickly resolved for the patron still may result in a lot more work. Snowball effect.

Statistics updated

April’s statistics are now included on the statistics page.

Statistics updated

March’s statistics were added to the statistics page. There were 19 reports in March, eight of which remain unresolved. A couple of those ongoing issues are familiar titles with new problems. Several problems are similar:

• managed coverage dates don’t appear in the MARC record (Review of Income and Wealth, Journal of Financial Research, Harvard Business Review)
• content doesn’t match what’s available through other resources (Journal of Experimental Therapeutics and Oncology, Hydrocarbon Processing)

Statistics updated

February’s numbers have been added to the statistics page. I had another direct-from-patron email, which brings the grand total up to four. Although I think it’s helpful to filter patron reports through the reference department, I like (and miss) working with patrons.

As I’ve mentioned in past posts, I keep noticing ways that my statistics are faulty. For instance, my statistics for average days taken to resolve a problem look pretty impressive: most problems have been solved in 1-2 days. Actually, only the resolved problems have been resolved that quickly. The unresolved problems are taking much, much longer. If you take into account all of the ongoing problems, there are going to be a lot of high numbers to skew the statistics. What does it matter that I’ve resolved 100 problems in a few hours if there are 40 that have been “ongoing” for weeks or months?

Statistics updated

This month’s statistics show how busy it’s been. Not only is this the first time that the mode days taken to resolve a problem is higher than the average, it’s the third time that unresolved problems outnumber resolved problems. That’s not a statistic I’ve made into a graph (I think it seems somewhat arbitrary), so I’ll give a little recap of the months with the lowest response rate:

• 8/06: 14 reports (9 ongoing)
• 6/07: 9 reports (5 ongoing)
• 1/08: 16 reports (11 ongoing)

Three is also the number of times we’ve ended the month with all that months problems resolved (pay no attention to the earlier, ongoing problems):

• 7/06: 9 reports (0 ongoing)
• 8/07: 6 reports (0 ongoing)
• 9/07: 6 reports (0 ongoing)

Anyway, January 2008 was a busy month and today’s been a busy day. I’ve only really done four things all day: an IP authentication question, a registration problem, a switch to online-only, and these statistics. When I put it that way it sounds like nothing, an easy job, but the intricacies of each task compounded make for one hectic day. Usually I’m too busy to remember everything I’ve done in a day.

Statistics updated

December’s statistics are added to the statistics page. Comparing six months of 2006 statistics to a full year of 2007 statistics, it’s easy to see how faster I’m able to resolve problems. It wasn’t until December 2006 that I could close a troubleshooting report in under two days; last year the average (of my average) was two days.

This is primarily an indication that I’m able to recognize how to resolve most queries right off the bat; it is not an indication that things are getting easier. My inbox is still full of unread messages relating to resolutions, and messages I’ve read by may not have acted on. I have not comprehensively or systematically followed up on previously unresolved problems (a mix of loose ends and continuing problems).

I was in a meeting last month with colleagues from our medical library who work with e-resource, and we talked a little about the statistics that we keep. I realize I should reevaluate the types of data I gather because it doesn’t give an accurate picture of the work that is involved in e-resource management. Seeing how long it takes (on average) to resolve a problem doesn’t show how many emails were sent, how many hours were spent, or how many times I wanted to pull my hair out (that would be an interesting chart).

(At some point I would like to at least streamline my classification of problems and resolutions to better identify how many problems are due to inappropriate subscriptions, inaccurate holdings, etc. I’ve been working on it slowly, but there’s more to be done.)

Statistics updated

November’s statistics are now included in the graphs on the statistics page.

I’ve been reporting to my boss (but not including in my charts) the number of problems resolved vs. the number of problems left unresolved at the end of the month. I had decided not to create a chart because it seems like an arbitrary measurement: an unresolved problem that was reported on the first of the month is more of an issue than one reported on the 31st.

I also haven’t been tracking those then-unresolved problems to see if they’ve ever been resolved. Here’s a quick look:

Oldest ongoing problem: August 9, 2006
Number of ongoing problems as of today: approximately 32, representing 26 unique titles

To date I’ve tracked 242 total incidents, so those 32 unresolved problems mean that 13% of troubleshooting reports have not been resolved since June 2006. (Eleven, or 34%, have been pending for 12 months or more.)

It would be nicer to have that those numbers closer to 0%. Would another person or two tending to problems help bring the percentages down?