Issues

Login

Enter your email address to receive posts by email:

Delivered by FeedBurner

Special TCR Opinion Editorial: “Mid-Semester Platform Changes: Guidelines for Smart Vendors”

Reported by Kathy Perry, Director, VIVA (www.vivalib.org/)

**ORIGINAL POST**
From: Kathy Perry kperry@gmu.edu
Reply-To: liblicense-l@lists.yale.edu
Date: Mon, 1 Mar 2010 19:16:43 EST
To: liblicense-l@lists.yale.edu
Subject: Mid-semester platform changes — please don’t!

This is an open letter to Vendors and Publishers and I apologize if this is not the appropriate listserv.

Although it seems obvious, apparently it isn’t, so I feel the need to make this statement:
“It is usually a very bad idea to make platform changes in the middle of the academic semester.”

We’ve had 3 vendors announce interface changes within the past 2 weeks — one is causing significant problems, despite the usual promises of it being “seamless.” And these are not business databases, but ones where the academic community represents major portions of their customer base.

While I realize the calendars are not the same for all colleges, universities, count r i es , or cont inent s , some consideration has to be given to the academic calendars. Major changes can (and often do) produce confusion for our students, faculty, librarians and staff throughout the library. The impact can be observed in broken links in course management systems, MARC records that have to be reloaded, bibliographic instruction materials requiring revision, reference staff and virtual reference staff requiring retraining, and lost use data, to name just a few aspects coming to light in the wake of these “seamless transitions.”

Thank you,
Kathy Katherine A. Perry
VIVA Director

On Monday, March 1, 2010, I posted a little email to the liblicense listserv as an open letter to vendors and publishers stating that “Although it seems obvious, apparently it isn’t, so I feel compelled to make this statement: It is usually a very bad idea to make platform changes in the middle of the academic semester.”

Over the next few weeks I received many emails from other librarians who agreed with me and my email was re-posted to at least one other listserv. I guess I wasn’t the only one who felt that way.

Quite interestingly, I also received one email from a vendor requesting participation in a focus group reviewing their platform change. (While I appreciated the invitation, this is not a product my consortium subscribes to and I really couldn’t spare the time.)

My consortium, the Virtual Library of Virginia (VIVA), has contracts for approximately 60 different products on about 25 different platforms. This semester we experienced 3 major platform changes, one of which was a textbook case study not only of the worst possible transition but also of the worst possible customer service following the worst possible transition.

There aren’t any written rules on this, that I’m aware of, but here are some guidelines to avoid becoming the next case study in the worst possible transition:

1. Choose a time for the transition or maintenance that does not conflict with the academic calendars of your clients. For those of us in the Northern Hemisphere, that pretty much limits major interface changes to June or July, after the spring semester and well before the beginning of the fall semester so that librarians can prepare bibliographic instruction materials.

2. Even better, allow your clients to choose when they want to make the transition. Many of our vendors have done that and it has been up to us to decide if we want to make one decision for all members of the consortium or let each institution make their own decision. This has worked very well in the past.

3. Be sure the techie folks are not running the show by themselves, especially not when it comes to determining the transition timing. Please give the sales folks some credit for knowing their clients and integrate that knowledge into the whole organization. (When I draw an organization chart of my vendors, I often show the techie folks in their own world, completely unconnected to the rest of the organization or to their clients. This only leads to problems.)

4. Be sure to test and retest the new interface with an eye to service ramifications on our libraries. Techie folks apparently don’t always know the ramifications of the changes they make it can cause tremendous work and additional headaches for every library customer. (Look, I’m sorry to have to say this, but exactly how could a major vendor change the interface and not know that links to MARC records would no longer work?) Libraries are very complicated organizations these days and poorly planned and poorly executed interface changes can require significant and burdensome procedural changes in several departments of every library. For example, when the MARC records no longer are correct, every library had to find and download new files and reload records to help make the product discoverable again. Other interface changes have required redoing URLs on the library web, alerting faculty and students to changed URLs they may have bookmarked or may have incorporated into their management courseware, redoing bibliographic instruction materials and research guides, changing procedures for gathering usage data, etc.

5. Communicate clearly.

a. Provide sufficient warning that a transition is about to occur. Please send out the notice well before the event. If the event is going to take place over the weekend, it doesn’t do much good to send a notice out after 5pm on Friday.

b. If you’re doing this, think about the most effective communication strategy and don’t just use Facebook (I kid you not — this has happened. Facebook is cool, but it is definitely not the best way to reach all of your customers. To point out the obvious [again], not all of your customers will have chosen to be your “fan” and will not receive the notice — duh.)

c. Please be specific about the time and the time zone when the maintenance will occur. We often get email notices without any recognition that our students and faculty may, in fact, be in several different countries over several different time zones. We’ve got distance education students in ships at sea , faculty doing research all over the world, and so on.

d. If your customer is a consortium, send a notice to the consortium central office. (Yep, the consortium office should not be the last to hear about a major platform change.)

e. Provide correct information and clear instructions if procedures are involved. This is especially important if action has to be taken by each individual institutional library. In our textbook case study for the worst possible transition, not only did the initial communication provide incorrect information about the MARC records, but we were inundated with 4 personal phone calls following up on the disaster and not one single email with correct instructions we could share with our members. We were reduced to begging for correct instructions. Note to vendors: proper customer care does not mean pulling in the sales force after the disaster and inundating the clients with multiple personal phone calls when a simple e-mail message with clear instructions would have been much more helpful and much, much more appreciated.

Finally, let me say our vendors and publishers are generally wonderful people and fully aware of the academic calendars — they know to avoid major maintenance down times when our students are most likely to be studying and they know better than to change the way the interface looks in the middle of the semester. They know we will groan and roll our eyes upon hearing the usual assurances that “the transition will be seamless” (really?) and they know that we expect and deserve to see adequate warning about any major changes. Still and all, it is always a surprise when one of our providers appears to run a multi-million dollar business as if it didn’t exist to serve clients and with little apparent reflection on standard business procedures for either technology or customer care.

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>