UBC: Collections Management & Planning Forum (Dec. 2011)
ALA MidWinter 2013 - Electronic Resources Management Interest Group meeting - Creating a Sustainable Renewals Calendar presentation
1. Meeting the Challenge:
Creating a Sustainable Renewals Calendar
Danielle Westbrook
UBC Library
@dwattersw
LITA/ALCTS
Electronic Resources Management Interest Group
2013 ALA Midwinter Meeting
2. Today’s Topic
Meeting the Challenge:
Successful Electronic Resources
Management in the Absence of
a Perfect System
Presentation Focus
• How UBC devised a plan for a local system to counter missing
functionality in our ERM
• We set out to update how we manage renewals dates and workflows
• While we rely on our Serials Solutions Resource Manager, our new
renewals process runs parallel to our ERM and could be used as a
standalone process
* This slide was altered from the original presentation to include additional speaking points.
3. Why Renew?
Due to the increasing pressure to provide greater justification for electronic
resource renewals, UBC Library embarked on the Why Renew? Project in summer
2012 to analyze and improve how the Library manages renewal decision-making.
Project Priorities
1.Initial implementation of our ERM (Serials Solutions 360 Resources Manager,
along with 360 COUNTER)
2.Establishing a renewals calendar to consolidate important renewal information
and make the renewals process easier across the Library
* This slide was altered from the original presentation to include additional speaking points.
4. Why a Renewals Calendar?
Purpose
•Track and display important renewal dates
•Allow the library to proactively assess electronic resources
•Permit strategic decisions about realigning/grouping renewals
Requirements
•Sustainable
•Accessible to all stakeholders
•Integrate into existing work
5. We created a renewals calendar...
How did we do it?
1. Mapped workflows for how we were disseminating renewal
information at the time
2. Identified where UBC renewal data was living
3. Assessed our ERM’s functionality for managing renewals
4. Investigated how other libraries were tracking renewals
5. Developed a plan for managing and calendaring our renewal
data
7. What about our ERM?
• Serials Solutions 360 Resource Manager
• No calendar view
• Renewals data stored at the license-level
The Vendor The Vendor
Wrong renewal
License Invoice
alert for
Jan. 1 – Dec. 31 Sept. 1 – Aug. 31 resource C
A B C
* Based on the functionality of Resource Manager in summer 2012. Serials Solutions recently upgraded
Resource Manager so that renewals are resource specific (at the journal/database level). This is great
news. I talk about how this affects our Why Renew? project work at the end of the presentation.
8. What are other libraries doing?
Informal Survey: What sorts of strategies and tools (calendaring
software, ERM alerts, etc.) do you use to make renewal decisions?
Homegrown solutions in lieu of or alongside an ERM
- “Giant unwieldy Excel spreadsheet”
- Separate renewals database (built in-house)
- Using Google Sites to house vendor contact, licensing, statistics, and
a renewal calendar
Looked for Literature on Library Renewal Calendars
(unsuccessfully)
Shapiro, Steven. (2010). Using Google Calendar as an Email Alert
System for Electronic Resource Renewals. Journal of Library Innovation,
1(1), 52-56. Retrieved from: http://www.libraryinnovation.org/.
9. So what did we do?
Simplified
• Direct subscriptions only
• Identified core information for a renewals calendar
(resource name, end date, fund code and out
Miscellaneous PO notes field)
• Generic non-renewal notice period of 90 days
(determined based on an analysis of the renewal terms
outlined in our resource licenses)
Paid attention to data integrity
Looked to currently supported tools first
• Voyager ILS Module
• Microsoft Outlook
* This slide was altered from the original presentation to include additional speaking points.
10. Renewals Query = Renewals Report
• Wrote query to
collect renewal
data stored in our
Acquisitions ILS
module (data
formerly gathered
by hand)
• Created calendar
upload from report
• Distributed report
library-wide
11. Renewals Report + Calendaring template
Microsoft Outlook CSV. Template
• Copy core information from the renewals report into template
• Minimal reformatting
• Run report on a monthly or quarterly basis to update calendar
13. Speaking Points for Previous Slide…
Microsoft Outlook
• The email and calendar software tool already being introduced across the library
• Can share a calendar across the Library system
• Once shared the calendar can live alongside the employees individual work
calendar
• By creating a community calendar that sits next to employees’ work calendars,
we hope this helps integrate renewals work into everyday work.
.CSV Template
•Colour code your line item. In our example:
• Green = Resource end date
• Red = termination date
• Yellow = End date for resources that don’t review yearly review*
*An important workflow to think about – what resources are so core and
fundamental that you could instead view them every other year, or every three
years? And how can you systematize evaluating these resources for renewal?
* This slide was altered from the original presentation to include additional speaking points.
15. Speaking Points for Previous Slide…
Calendar View
• Each renewal event includes the 4 core pieces of information
outlined earlier (resource name, the fund code for the specific
branch/subject area, the end date, and all text stored in the
general PO notes field).
• It is the end date that is stored in the calendar – the generic 90
day non-renewal period is applied in the workflow (i.e. In January,
analyzing April/May subscriptions).
* By having the fund code(s) in each resource, selectors can
search the entire calendar by their fund code(s), and only see the
upcoming renewals that involve them. For further information
around price and vendor, they can view the renewal report that has
already been uploaded onto the staff Intranet.
* In our system, the fund codes act as a way for each selector to
search for renewals that require their attention. As well, they act
as a way for us to divide renewals into broad subject areas.
* This slide was altered from the original presentation to include additional speaking points.
16. Moving forward
This is still a work in progress. At the end of the Why Renew?
project we had a renewals calendar, but the ongoing
implementation hasn’t happened.
As previously mentioned, Serials Solutions updated their Resource
Manager to permit resource-level renewal management and more
renewals fields (which is what we are looking for). We will need to
re-evaluate the functionality that now exists in our ERM to see if
we can begin storing our renewals information there.
Although this change to the ERM comes on the heels of us
developing a UBC-specific solution to managing renewals, the Why
Renew? project has made us more knowledgeable about our needs
for storing renewals data; it forced us evaluate workflows and data
management – something we needed to do, whether to maintain
our own solution or to move our data to our ERM.
* This slide was altered from the original presentation to include additional speaking points.
First off, I’d like to thank our meeting Co-Chairs, Caitlyn Lam and Benjamin Heet, for organizing today’s meeting. I’m very excited to be here - My name is Danielle Westbrook, and I am an Electronic Resources Licensing Specialist at the University of British Columbia. UBC is a 4-year public university in Vancouver, British Columbia, Canada. To give you an idea of our size – we have approximately 56 000 students and 14 000 faculty and staff, spanning two campuses and several satellite facilities.
In keeping with today’s topic, “Meeting the Challenge: Successful Electronic Resources Management in the Absence of a Perfect System” – the focus of my presentation is on how we at UBC devised a plan for a local system to counter missing functionality in our ERM. We set out to change how we manage renewal dates and workflows. Our end result is a process that runs parallel to our ERM. Although we do rely on our Serials Solutions ERM – the solution we found for managing renewal dates can be used as a standalone system.
Earlier last year, the Collections and E-Resources divisions were facing increasing pressure to better justify why we were renewing electronic resources. So, in the summer of 2012, the E-Resources division embarked on the Why Renew? Project – this was done in conjunction with our Serials and Acquisitions divisions, and in consultation with our Assessment Librarian and Collections Management & Planning Librarian. So this project has truly been a collaborative process.Faced with the task of answering the seemingly simple question (why should we renew each resource), the project team set to work laying the groundwork for sounder renewals decision making.Our two main priorities were: The initial implementation of our ERM (Serials Solutions 360 Resource Manager, along with 360 COUNTER)and establishing a renewals calendar to consolidate important renewal information and make the renewals process easier across the Library.Today I’m going to talk about our experience updating our renewals workflow.
Why a renewals calendar? What purpose would it serve?We wanted a way to easily display all of the important renewal dates. The calendar would also allow selectors and librarians across the library system to view upcoming renewals and make proactive decisionsAnd the calendar would facilitate strategic decision making about realigning renewals and grouping them with vendorsHowever, if we were going to build a renewals calendar,It had to be sustainable – something we could maintain. Dates and pertinent information needed to be easily migrated in. This wasn’t going to be something that would be manually updated.We decided the calendar had to be accessible – available - to all stakeholders…And along those lines, it needed to integrate into existing work (as seamlessly as possible)
In the end, we did create a renewals calendar, and a plan to keep it goingWe mapped the workflows for how, at the time, we were disseminating need-to-know renewal information. From that process, we identified where our renewal data was living – and what it looked like.We assessed our ERM’s functionality for managing renewals, and investigated how other libraries were tracking them.And then at the end of the summer, we developed a plan for managing and calendaring our renewal data
So we started by mapping our existing renewals workflow.I should qualify that the workflow on the slide is just for our direct subscriptions. Although the Why Renew project looked into how our consortium manage renewals, we decided not to focus on them because of the framework developed and managed by our consortia to facilitate renewals decision-making. Our renewals workflow for direct subscriptions started with a renewal notice being delivered. Following that, either a librarian or library specialist gathered usage stats and pertinent information that they would then send to the applicable selector and inquire if they wanted to renew.Although these steps seem simple – I have isolated them on the right-hand side of the slide – these few steps actually represent a fair amount of work. Even if you put aside the usage statistics, we had someone going into several different areas of our Acquisitions ILS module, sometimes looking at invoices or even licenses – putting together renewals information. UBC has over 1300 electronic database and single-title subscriptions – so collecting and disseminating basic renewals information represents a lot of work which, but way of how we are storing renewals data, was time consuming. In addition to being a manual process, it was also reactive. For the most part, the workflow starts with a renewal notice being delivered. Between the arrival of the notice and the renewal deadline, selectors did not necessarily have enough time to evaluate the resource and consult with faculty and students. In such cases, our option was to renew. * no noticeThrough evaluating our workflow, we also began to realize that data was not consistently stored in the same field, or formatted the same way. We were using free text fields to store longer notes, as well as date information, and data better suited to controlled field types.
At the start of the Why Renew project we looked to our ERM to help us generate our calendar.Now, 360 Resource Manager does not have a calendar view. Nevertheless, we though we could still use it to manage our renewals data.At the time of our project (summer 2012), renewal data was stored in Resource Manager at the license-level, and all renewal alerts were license based. So – if we have a license with a January 1st to December 31st. subscription period and a 60 day non-renewal notice. When we first sign the license, it governs two resources. Farther down the road, we decide to subscribe to another resource from the same vendor. The resource is still governed by the original license, however the subscription period is different – it runs September 1st to August 31st. But because the renewal data is stored at the license level in the ERM, the renewal alert for resource C would be wrong. Didn’t want work aroundI should note, that this slide is based on the functionality of Resource Manager in summer 2012. Serials Solutions just recently upgraded Resource Manager so that renewals are stored as the resource level – which is great news.
Once we determined that we weren’t going to store our renewals data in our ERM, we decided to informally survey other libraries to ascertain how they managed their renewals.This was done through posing our question to listservs. More often than not – we heard about homegrown solutions in lieu of or alongside of an ERM. Giant spreadsheets – very common We heard about a library building a separate renewals database, from scratch And another library discussed using Google sites to store everything from contact information to their renewals data (in a calendar!)And after hearing from other libraries, we also looked for literature on library renewal calendars. Unfortunately, not a lot has been written on this topic. Shapiro does talk about using Google Calendar to create alerts – but al in all – we weren’t able to find a great deal.
From all of this, we got an idea of what we could do. We started off by simplifying things We decided our calendar would just track direct subscriptionsWe identified the core information that we needed to provide in a calendar for selectors and technical services staff: Resource Name, End date, Fund Code, and our Miscellaneous PO Notes field Conveniently, all of this information is stored in our Acquisitions ILS Module, in some form or another – we are a Voyager shop We decided on a generic non-renewal notice (of 90 days) – we were not going to worry about tracking each resource’s unique non-renewal notice periodIn order to get a handle on what a new renewals workflow should involve, we needed to better understand the confines of our subscriptions – So…We looked at the licenses for all of our resources – and in addition to many not stipulating a non-renewal notice period, most were 30 or 45 days, some were 60, and even fewer were 90 days. A very small number of resources have renewal periods that are longer than 90 days – they are so few, that they can be managed on their ownWe also decided that we wanted to start with some small gains for data integrity – the biggest one, was finding a new field for end date – a controlled field for date information (previously it was being stored in a free-text field, in many different format styles – some non-standard) Although our existing workflow didn’t support managing renewals information efficiently, we were loathe to spread our data across yet another system – at least not before trying again to find a solution using tools we already supportedGiven that a lot of the core information we identified as being important for the renewals calendar already lived in our Acquisitions ILS module, with the above mentioned changes, it became our tool for storing and managing this data. I should note that Voyager Acquisitions isn’t built to be a renewals tool – so it involved us redefining an unused date field. As well as creating a custom query to pull together all pertinent renewals data being stored in Acquisitions to generate a report. From the report, we could populate a CSV. template to upload into Microsoft Outlook – Outlook being the calendaring software that is supported at UBC Library and being introduced across the system.
Here is the gratuitous shot of our Renewals Report query in Microsoft Access. Through our query, we generated a renewals report.Although for the calendar, it was our intention to pull out just the “core” information for our renewals – the query itself pulls together vendor name, yearly costs since 2004, currency and other information. So the entire report– although too dense and multifaceted to be pushed into calendar form, collects together all of the information that we previously had someone collecting individually, by hand.So the renewals report is really multi-purpose: components of the report are parsed out for a calendar upload, but the report itself can be uploaded onto the staff intranet. Selectors can then navigate to the full report once they have checked the renewals calendar and have seen what renewals are due in the upcoming months.
From our renewals report, we populate our calendar template. Because we were using Outlook, I simply downloaded a copy of an event in csv. format, and created a template from that.The core information is copied from the report into the template. There really is minimal reformatting. As this work represents a new workflow – from running the Access query to updating the Outlook template – we created a how-to document. In terms of updating the calendar, it customizable – it can be a monthly process, or done quarterly.Once the template is uploaded, you have your renewals calendar.
The renewals calendar we created is a shared calendar. But by going with Outlook, the email and calendar software tool already being introduced across the library, we could not only share the calendar with staff and librarians across the system, but the calendar itself, once shared, could live alongside the employees personal calendar – making it really easy to click into the calendar and check out what renewals were coming up 3 months down the line.Although at first the idea of having a calendar view in our ERM, or on the Intranet, seemed to be the sensible choice – by creating a community calendar that sits next to employees’ work calendars, I hope this helps integrate renewals work into everyday work. You don’t need to log into a whole new system to keep on eye on upcoming work as you are already logged into our email/calendar when we are at our desks.In the template itself, you are able to colour code your line items. In this view – green represents standard renewals, red are termination dates, and for this example, yellow represents end dates for resources that don’t require yearly review. Which as an aside, I think it an important workflow – what resources are so core and fundamental that you could instead view them every other year, or every three years? And how could you systematize then evaluating these resources for renewal?
In the calendar view we have 4 main pieces of information (resource name, the fund code for the specific branch/subject area), the end date, and all text stored in the general “notes” field.By having the fund code or fund codes in each resource renewal, selectors can then search the entire calendar by the fund code, and only see the upcoming renewals that involve them. Then for further information around price and vendor, they could view the renewal report that has already been uploaded onto the Intranet.I should note that here the fund code acts as a way for each selector to search for renewals that require their attention. As well, it also acts as a way for us to divide renewals into broad subject areas.
Changing workflows and how we store information takes time. During the project, 1.5 FTE’s were hired for the summer just to work on renewals. Although a working solution was devised by the end of the project, we still needed more time – to help facilitate the implementation and continue to tweak and improve the workflow. Moreover, Serials Solutions recently made changes to their Resource Manager and how renewals information is stored. It can now be stored at the resource-level – which is what we are looking for. So we will need to re-evaluate whether or not the functionality now exists to begin storing our renewal data in our ERM – which is what we are looking for. Although this change to the ERM comes on the heels of us developing a UBC-specific solution to managing renewals, I think our project forced us to do the necessary leg work – that we would need whether it was for developing our own solution, or moving our data to an ERM.
