Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Case Findings
Once library items were received, it was the acquisition staff's role to register the items into the ILS and establish their barcodes. The Acquisitions module of the legacy systems the library was using allowed for the batch barcoding of all copies of the same item. The Acquisitions module of the new ILS apparently didn't do that, and it required a barcode to be established individually for each item.
Given that the library's acquisitions staff was responsible for this task, they attempted to do so using only the Acquisitions module of the new ILS. Our investigation found that the new ILS supported batch barcoding, as well as assigning sequential barcodes—when a new item record was being created from within the Cataloging module. (The process is outlined in the following section.) In the new ILS, the tasks for barcoding items were attributed to the cataloging staff of the library, whereas that task was assigned to the library's acquisitions staff, and their homegrown system had been designed around this task assignment. The designers of the new ILS simply made a different choice.
One reason that the library staff didn't discover this fact on their own was that users of the Acquisitions module didn't have access to and never saw the capabilities of the Cataloging module, and users of the Cataloging module didn't have any need for batch barcoding and therefore didn't explore this capability. Further, even though this issue was discussed internally, no one at the library had a full view of all the capabilities of the ILS, allowing the staff to believe that customization of the Acquisitions module was the only option.
Giving the acquisitions staff access to the Cataloging module, even if limited to just to the barcoding function, would resolve the barcoding issue—with no customization at all!