Print

Introduction xi compared to our online public access catalog (OPAC) that just searched the records in Sierra. Not only had the library expanded their collection electronically and changed the way our users accessed our holdings, but we had added new physical collections as formats changed and to meet the interests of our users. Each time we added a collection, we would add a location with a matching item type. Yet we never removed an item type, location, or other data point if we stopped collecting in that area or format, and they were integrated into other collections. On the patron side, as we joined several lending agreements, made special agreements with local schools or businesses, and the state library instituted statewide lending, we would add new user groups and clas- sifications to make sure that when an item was borrowed, it was for the right length of time. We also implemented new item statuses to prevent items that we didn’t want borrowed by different groups from going out. As with item types and locations, we didn’t delete old user groups as they changed or were no longer needed. Along the same lines, patron groups and item types are often used to col- lect statistics, and using location-based item types made it difficult to get sta- tistics when asked. Just like most libraries, we report statistics to many different entities: the state, Association for College & Research Libraries (ACRL), the university, etc. Every few years the statistics we are asked for change, and as part of this project we want to be sure our item and patron data is flexible so that the next time there’s a change to what is requested, we can easily fill the request. Along with reporting reliable statistics, it has become more important that we track collection and service trends to support our position in the university and advocate for new resources. We also wanted to review many of our long-standing practices around ILS permissions. Our standard practice was to give a new employee the same per- missions the former employee or other employees in the same role had with- out reviewing what was needed. This was problematic for several reasons first the library had gone through several restructures and creation of new departments as it grew and offered new services. The second reason it’s prob- lematic is that, as an individual’s responsibilities changed, we would add what they needed, but many times a new employee wouldn’t have the same respon- sibilities and wouldn’t need the same permissions. Finally, we rarely reviewed permissions when new features were added or bugs fixed during ILS upgrades. This frequently meant that even if a new feature that would improve a work- flow or internally created workaround was added, if new permissions were needed, users did not receive them automatically. All of this meant that when I started I was given permissions for everything my predecessor had, which included permissions for functions and modules that our library doesn’t use.