"The higher you climb, the deeper you get."
Patrick Meyers, from his play, K2 (1983)

I remember when I first became an acquisitions librarian. The year was 1983, and the library was at a small state university in Tennessee. Our "automation" consisted of OCLC cataloging and a dedicated Dialog keyboard/printer for online reference searches. By the time I left in 1987, we had started ordering books with a Baker & Taylor Betaphone and I produced a monthly acquisitions list on my sewing machine sized Compaq personal computer which I brought in from home. From Tennessee I moved to another public university in Maryland where we had a full-fledged online catalog, although no acquisitions module. In my final year at Maryland we began using a stand alone microcomputer-based acquisitions system. Also during my last few months in Maryland, I served on the statewide committee that selected the university’s next generation library system - this time to include an acquisitions module. Just as the committee made its selection, in 1990, I moved on to the Indiana University School of Law’s library as that library was bringing up the Acquistions/Serials module of a fully integrated system.

Joining a library that already had an automated acquisitions system made me feel like I had reached the top of the mountain. I assumed that I could now rest on the summit, admiring the view and effortlessly (with just a few keystrokes) order, receive, and pay for all library materials. It didn’t take long for me to realize that my rest would be brief. What has taken a little longer for me to learn is that climbing one peak is not as satisfying as climbing an entire mountain range. And while many of the peaks in that range may be smaller than that first one you climbed, each will be filled with its own set of risks and challenges. I’ve recently run into a few of these peaks in the form of our university’s decision to implement a second-generation automated system.

While one might argue that bringing up a second system is far less daunting than bringing up a library’s first system, take my word - there are plenty of unique challenges presented to those moving from one system to a new. From the relatively minor problems associated with terminology (what is referred to as an "item" record in one system may not be the same thing as an "item" record in the new system) to the more complex technological questions (will the data in the old system properly transfer into the system?), merging from one system to another will challenge any acquisitions librarian to evaluate the way things are done. And while it is tempting to try to tweak the new system into working like the old system, it is essential that you expand your vision to see just what the new system can do that the old system could not.

Luckily, the change from one system to another does not happen overnight. In our case we have had more than 18 months to prepare for the change. Still, as we move into the final stages of the actual switch (scheduled for January 2001) one can’t but help feel a little apprehensive about such a monumental change. Don’t get me wrong: we all recognize the advantages of moving to a system that takes advantage of the latest technologies - after all, our current system has been running for more than ten years and is probably using technology that was created 15 or more years ago. Intellectually we all know that the new system will allow us to do things that are just not possible with the old, but still there is nothing quite as comforting as working with something you already know. Sure the old system never did exactly what we wanted, but we’ve managed; we’ve massaged and tweaked it to the point that it did what we needed it to do. And while we often complained about certain aspects of the system, I’ve noticed that as we’ve moved closer to the big day the complaints have almost completely ceased. In fact, it is not uncommon to hear someone ask why won’t the new system do it the way the old system did.

As I said, most librarians who find themselves in this position will not be alone, and that includes acquistions librarians. Your colleagues at your library and your colleagues at your automation vendor will all be involved in the process. Chances are that each professional will be focusing on specific aspects of the merger. You, no doubt, will be focusing on the acquisitions and/or serials aspects. That has been the case in my particular situation and, even though the process is not yet complete, I’d like to offer up a list of questions that I think any acquisitions librarian should ponder as the planning process begins. The answers to these questions will largely be influenced by the two systems being merged and may not be fully answered until the new system comes up, but still, posing the questions will force you to start thinking about some of the specifics of how the two systems will blend. I’ve broken the questions down into three categories, but I suspect there could be many more.

1. Orders. Do the data fields in your current order records correspond to the data fields in the new system’s order records? If not, what can be done to insure that most crucial data is transferable? Will you need to "cleanup" your old orders before the data is merged? What sort of cleanup will be needed once the orders are transferred over to the new system? How does the new system distinguish between order types (firm, standing, subscriptions, etc.)? Will the new system be able to recognize the purchase order numbers used in the old system? What sort of flexibility do you have creating free-text notes on your orders? Will you be able to place and receive orders during the period of the actual transfer of data? If not, what are you to do with the materials that arrive during this period?
2. Funds/Accounting. Will the new system use the same fund structure? If not, how will the new system deal with orders merged with funds that were created in the old system? Will the conversion take place at the end/beginning of the fiscal year? If not, how will you track your commitments/allocations in a dual accounting period? How does the new system deal with the fiscal year rollover and how will you have to prepare for it? What accounting reports will be available in the new system and will they provide the data your managers need (and are accustomed to receiving)? If both the old system and the new system are down during the initial data transfer, how will you post your payments to insure that they are recorded when the new system comes up?
3. Vendors. Will the new system recognize your current Vendor records? Do the data fields in your current vendor records correspond to the data fields in the new system’s vendor records? How does the new system communicate with vendors (electronically vs. paper?). If electronically, do your vendors have a history of interfacing with the software of your system vendor. If by paper, will the format (size, layout, canned messages, etc.) of the correspondence create problems for your vendors? How does the system deal with vendors you only use once?