Biz of Acq -- The Development, Growth, and Maintenance of a Web-Based Book Order System

Against the Grain, Nov 2013

By Michelle Flinchbaugh and Robin Moskal, Published on 11/01/13

A PDF file should load here. If you do not see its contents the file may be temporarily unavailable at the journal website or you do not have a PDF plug-in installed and enabled in your browser.

Alternatively, you can download the file locally and open with any standalone PDF reader:

https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=2322&context=atg

Biz of Acq -- The Development, Growth, and Maintenance of a Web-Based Book Order System

Biz of Acq -- The D evelopment, Growth, and Maintenance of a Web-Based Book Order System Michelle Flinchbaugh 0 Robin Moskal 0 0 University of Maryland Baltimore County , USA Follow this and additional works at: http://docs.lib.purdue.edu/atg Part of the Library and Information Science Commons Recommended Citation - Biz of Acq — The Development, Growth, and Maintenance of a Web-Based Book Order System by Michelle Flinchbaugh (Acquisitions Librarian, University of Maryland Baltimore County) and Robin Moskal (Head, Collection Management, ILL and Accounting & Receiving, Acting Head of Reference, Albin O. Kuhn Library & Gallery, University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore, MD 21250; Phone: 410-455-2341; Fax: 410-455-1061) <> Background Developing and maintaining a home-grown system of any sort is a major labor-intensive effort. UMBC’s Albin O. Kuhn Library developed a home-grown Web-order system in 1999 and has maintained it for the last ten years, adding enhanced features over time in response to patron demand. UMBC is a mid-sized doctoral institution with 12,000 students and just 24 librarians. Academic departments do the majority of the ordering of library materials, with some input from librarians from time to time. Each academic department has a library liaison/selector who represents the department for ordering materials and is responsible for spending the library funds allotted to the department. The liaison, or a designee, places requests for materials purchases through the online order system or via BNA Collection Manager. We no longer accept typed orders or circled catalogs. UMBC developed its Web order system in direct response to problems with a Web email based order system that generated numerous faculty complaints. The email based Web page sent the orders to selectors who then forwarded them on to the Collection Management department. Collection Management printed them and gave them to Acquisitions. Hundreds of individual email orders were being sent at a time, and some would be missed in the forwarding, and some would be forwarded multiple times. Additionally, orders could sit in email while people were on vacation, away for the summer, or on sabbatical. The library received so many complaints regarding lost orders that in 1999 the Library Director mandated that the Acquisitions Librarian fix the problem and insured that a Systems Librarian’s time be spent on it. The System UMBC’s Web order system has different interfaces, depending on whether the person accessing the system is a member of the public, an academic department liaison, or a library staff member. The form that the public sees when they click on the link from the library homepage allows anyone to request that materials be purchased (See Figure 1). Requests are forwarded to the appropriate liaison who decides whether to purchase the material or not. The most minimal information required for requesting that an item be purchased are the patron’s name and email address and the item’s title and format. Additionally, a department must be selected for each order. When the item request has been submitted, a copy of the order appears. At the bottom of the form the requestor can choose between ordering another book, with carry-over of some key fields from the previous request, or ordering a new book. Priority is extremely important in the ordering process to both Acquisitions and Cataloging, so the priorities of Rush, Priority and Collection Building are all explained right at the top of the form. Departmental liaisons use another interface (See Figure 2) by logging in via the campus authentication system using their usual campus username and password. Liaisons are able to place pre-approved orders via this interface which go to library Acquisitions with no further actions necescontinued on page 58 sary. While they are logged in, liaisons can also approve or reject public requests for purchase, either individually or en-masse, or put requests on hold until a later time. Via this interface, liaisons may also review titles they have approved but haven’t moved on to “Cleared in Acquisitions,” review titles that have been cleared and ordered by Acquisitions, and review approved and denied requests for the past two fiscal years. They can also see generally how much of their materials budget remains for the fiscal year. Liaisons can also edit an order before approving it, by adding information to the order, changing the priority, adding reminder information to the remarks, and changing the patron name and email to the person who should be notified when the book arrives. Via this same interface, the Collection Management Librarian also has the authority to change the department that was originally selected or forward the request on to a different department for consideration. Staff Functions and Tasks Staff perform various other tasks, which include establishing users, monitoring orders, loading records, setting order statuses, and running reports in the Web order system, via a Microsoft Access interface (See Figure 3), allowing them to work without understanding Access or the database structure. Most tasks staff or students do on a daily basis are included on the interface. Some other more complex tasks are done directly with tables, queries, and reports, requiring a better understanding of Access. The Microsoft Access database is tied to the actual data in MySQL on a campus server via ODBC. Having the staff interface in Microsoft Access allows the Acquisitions Librarian to customize and add new features whenever needed. In order to have access to the Web order system behind the campus MyUMBC login, individuals have to be set up as users, and in order to be able to do anything, they have to be assigned departments to select against. When a liaison or selector changes, either Collection Management or Acquisitions staff can “Look for a User” to see if a person is established in the system already. If already in the system, they are simply given the new or additional department. If not already in the system, the person is input using “Input a New User.” Once established, a user can be assigned one or more departments or funds. Users are assigned a role for each department, either “Selector” or “Secondary Selector.” A “Selector” is the person primarily responsible for a fund, also known as the liaison. A “Secondary Selector” designation is given to additional people who have been given the authority to order against that fund. Some funds have two to three Secondary Selectors. The Web order system also provides lists of departmental library liaisons for the entire library in a couple of different formats. Selectors are alerted when there are orders for them to review (See Figure 4). At one point this process was automated and the system sent alerting emails, but at this time the campus server doesn’t allow for this. Therefore, acquisitions staff must manually monitor new orders coming into the system. They open a query in the system that displays all orders with a “new” status and then manually email the alerts. Twice daily Acquisitions staff retrieve approved orders (See Figure 5) and print them saving a back-up file of the set of orders. Queries are run automatically at the beginning and end of the printing process to insure that the number of orders being cleared matches the number of orders printed. If the number of orders in the two queries don’t match, orders will be lost and the process is aborted and started over again at a later time. All orders print with a cover sheet, and rush continued on page 59 Biz of Acq from page 58 orders are printed first, followed by priority, then collection building. Within each category, they’re alphabetized by department. An update query changes the status of orders from “Approved” to “Cleared in Acquisitions.” Once this query is run, these orders are un-retrievable, so this is the point where the process is aborted or continued depending on if the query numbers match the number of orders printed. Each department receives periodic Department Reports (See Figure 6), and each requestor receives periodic Requestor reports (See Figure 7). These reports are Microsoft Access generated HTML files and are sent via email, and they include the status of the various orders that were placed. These reports include items ordered and now in the library, orders rejected as already owned, and orders approved but delayed, including the reason (such as out-of-money or not yet published). To report the status of orders submitted via BNA’s Collection Manager (CM), records are loaded into the Web order system. CM requests are received and loaded on a weekly basis via an Excel file we receive from BNA. Any problems in the file are resolved and then the Excel file is imported into a load table in the Web order system. The BNA data is manipulated via a query to better match the data, then loaded into the main data table via an append query that maps the data into appropriate fields. The information included on the reports regarding the status of the order, differentiating a filled order from an unfilled or delayed one, is input manually into the system by student assistants. They search the system for each order, and when they find the appropriate one, they select the appropriate status and add any notes. The system automatically time stamps each disposition when it’s set. Staff check the students’ work for accuracy via a report. Reports are generally run and sent about once a week, both for liaisons and for requestors. Data is modified to new date range in a query, and that query modifies data in two different reports, one for the Liaison Reports and the other for the Requestor Reports. The reports are exported as HTML documents, creating individual files for each page of the report. This creates many files, one for each page of the report, and the HTML files are attached to emails and sent. Development This system began as a bare-bones system based on two pages of specifications written by the Acquisitions Librarian in consultation with the Collection Management Librarian. The specifications spelled out for the Web librarian what the system would have to be able to do and the specs also included everything the system could possibly do. The specs were very specific to our unique Collection Management arrangement with academic departmental control of ordering. We knew we had to monitor orders that weren’t getting handled by allowing the Collection Management Librarian to be able to approve all faculty rush order on any fund, and we also knew we needed to be able to quickly and easily change liaisons and selectors. The full list of possible features was prioritized. Our programmer at the time did the initial design of the tables in Access and the Web development. The database was originally in Access, and the Webpages and programming were done in PHP, Perl, and SQL. Throughout the development process, there was a great deal of back and forth, as the programmer developed the Access tables and Web-based public interfaces, and the Acquisitions Librarian developed all the staff portions of the system in Access. Initially the Acquisitions Librarian designed linked forms, queries, macros, and reports to print orders and revise their statuses, and later developed a minimal staff interface that allowed functions to be performed from one interface form with the click of the mouse. The Acquisitions Librarian continued adding additional staff functions over time as needed and as time allowed, with the system slowly evolving into the featurerich staff interface that now exists. Substantial testing of the system was done before roll-out due to the many complaints the existing process was generating. This caution insured that everything worked correctly and was satisfactory. Features were added and bugs were fixed via three-tier testing, by the Collection continued on page 60 Biz of Acq from page 59 Management and Acquisitions Librarians, then by library selectors, and finally by key faculty selectors. Wide-scale roll-out took place only when we knew the system worked well and that the faculty liked it. The system was introduced to selectors via written instructions and through numerous phone and e-mail questions. From the get-go, the system was a great success and the library received many compliments from users regarding it, although there was an almost instant demand for more features. Shifting from paper orders to the system was not mandatory but eventually all faculty willingly switched by choice. Migrations This system has had to migrate several times, which can be a huge challenge. Routine migrations to new versions of Access are generally smooth, with occasional minor problems that have to be resolved. The database is tested in new versions of Access and problems are corrected before moving everyone over. A huge server migration required moving the data to a new database from Access to mySQL, re-programming the interfaces completely, and linking the database to the Access interfaces via ODBC, and putting the system behind the MyUMBC login. Many problems resulted and we spent six months to a year finding, troubleshooting, and fixing problems, which in turn led to new problems. Enhancements The latest development of this system, the reports, were done just this year. Previously we had been sending the liaisons monthly financial reports for each fund, and an addition 20,000 copies of purchase orders to inform them of the status of their orders. It was time to be done with all of that paper mailing and we clearly needed a better way of providing information! The financial information was entered into the system and it was then added to the interface. A staff member now manually updates the free balances once a week. Improved reporting on order status was more challenging, because there was no system that included all of the requests we received, both from the online Web order form and from BNA. So we decided to see if we could import BNA data into the Web order system. We looked for ready reports that could be run in CM but none were appropriate. We then looked for a way to grab data from CM but couldn’t get it in a consistent format, so we discussed with BNA and they worked with us on this. Sample reports were tried as we worked on loaders and queries and found out what would and wouldn’t work, and BNA was readily able to accommodate what we needed. As soon as we had a successful load of BNA data, we began having students and staff entering dispositions and running test reports. Developing an interface robust and efficient enough for that production level work was hard, and there were major problems with the initial data loads from BNA and with the interface itself. For example, all orders placed on Mondays were inadvertently omitted from the BNA reports, and a glitch in how the system searched prevented all orders lacking authors from being retrieved. Beyond encountering and fixing major problems, inefficiencies needed to be fixed to allow staff to work better in the system. For example, we got dates to fill in automatically rather than requiring people to enter them. We rearranged searches based on frequency of use, and we improved tabbing in the entry form. As soon as we had a semi-working sample report, BNA provided a file with a year’s worth of orders, which we loaded into our system. Problems and troubleshooting continued for about six months, but now Acquisitions staff readily load BNA data A home-grown Web order system is best approached as a value-added service rather than a labor savings device. Development is labor intensive and requires substantial planning and testing, a programmer, and/or high-level Access skills and a lot of time. The learning curve for Access is steep and designing interfaces and reports requires a lot of time, testing and fixing. Software and server migrations are labor intensive and require a programmer, so some programming time continues to be necessary throughout the life of the system. Everything has to be tested again and again and again, as nearly every change breaks something else. Tasks for staff may include inputting information which is labor-intensive, and Librarian tasks may include providing documentation, supporting users, and troubleshooting problems. It requires a lot of cooperation and communication and Acquisitions, Collection Management, and the programmer all have to work closely together in developing new features or managing problems. Also, all have to work together in coordinating responses to faculty requests for new features and special reports. But the results can be worth it in terms of good customer service which demonstrates a willingness to work with faculty to streamline the ordering. In addition, the processes of ordering can be made more transparent to those outside the daily work who still need the information. Selectors and liaisons get quality electronic reports, which can instantly be circulated throughout an entire department. Selectors have instant access to free balances and to records of what’s been requested, and the outcome of those requests. Inputting orders is both fast and easy as using the “duplicate order” button allows them to carry key fields to their next order, and approving orders is both fast and easy as liaisons get a link in the email, and approve everything with one click when they log in. There’s no paper to shuffle and distribute to others in their department, and there are no more lost requests or requests that languish in mailboxes or on desks. There are just happy requestors! The system generates good-will toward the library.


This is a preview of a remote PDF: https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=2322&context=atg

Michelle Flinchbaugh, Robin Moskal. Biz of Acq -- The Development, Growth, and Maintenance of a Web-Based Book Order System, Against the Grain, 2013,