Yes we can! Implementing digitization requests in Alma

Editor's Notes

• #8: 8 Universities in NZ Main campus at Dunedin – recognised as one of the 16 mots beautiful campuses in the worl Home of NZ’s first medical school and of NZ’s only schools of Dentistry and Surveying
• #9: Libraries - Central, Law, Health Sciences, Education, Science, and Hocken (NZ published and unpublished collections)
• #10: Our goal was to simply the process for both users and Library Staff We were hoping that we’d be able to enable all requesting to take place within Alma/Primo and the workflows for processing the requests could also take place inside Alma We were also hoping we’d be able to make use of Home Delivery so Distance users could request both physical items and digitisation within the same interface Alongside that we had the opportunity to evaluate who we offered the service to and the types of material we made available for requesting
• #11: Our previous setup had evolved over time through availability of different technologies and changing policy decisions Web forms used to receive requests from users, then form would either emailed the request to Library Staff or store the request in a Database Each user had to identify themselves each time the placed a request and they also had to manually enter the citation into the request form Staff would then retrieve the item from the shelves and send it to the Reprographics Department for scanning If a title was in a different branch a request might be placed on it in Voyager for the item to be retrieved and scanned The Distance team was responsible for filling requests for Distance students whereas other teams were responsible for filling requests from Staff or for Storage items or for Interloans All up it was messy – users had to go to different places to request different types of material and different staff used different workflows to fill them
• #12: We implemented both Alma and Primo at the same time and we realised that we wouldn’t have a lot of spare time to implement digitisation requesting within Alma/Primo seeing as it wasn’t core functionality That was a good decision – implementation and the months following it were very busy and we didn’t have time for anything other than core functionality We were also aware that the Digitisation functionality in Alma was a work in progress and that it might need more development before it was ready for us to use
• #13: We started testing the functionality in 2014 – we did some basic setup and started trying to place requests but quickly found a major issue –we weren’t able to place digitisation requests on titles with multiple holdings We support 4 institutions and multiple campuses so we had many titles with multiple holdings so this was a significant issue for us Testing stopped while we logged it with Ex Libris and waited for a resolution
• #14: A resolution came in August 2015 (10 months after we discovered the issue) so we started testing again with a target of going live at the start of 2016 We found another issue (we couldn’t place requests on titles with no holdings) but we decided it wasn’t a showstopper so we decided to go live in December before the start of the 2016 Academic year
• #15: We went live in December 2015 and almost immediately struck a major problem we hadn’t seen in testing The “Requests – Recalculate after Inventory Update” job was cancelling some of the unfilled digitisation requests when it ran each night We turned off digitisation requesting while we investigated Ex Libris identified the issue as a bug We decided to try switching off the job and accept the outcomes of that rather than sit and wait for the bug to be fixed – as a result of this we were up and running again within a couple of weeks The bug was resolved in the February release and we were able to turn the job back on before the start of Semester 1 Other than that go live was successful!
• #16: We chose not to turn on a number of digitisation features because we weren’t convinced they fit our workflows The approvals feature meant that after we retrieved an item form the shelves it would then be put into an approvals workflow before being sent to be scanned – we decided to check the request was within copyright limits at the point or retrieval/scanning and respond to the user at that point if it wasn’t We decided to put our own copyright statement on the Primo request form and the email that gets sent to the user rather than use Ex Libris’s copyright functionality We decided to modify the Primo request form to simplify it. When the option to add specific citation fields (title, author, pages) to the request form came along we decided to stick with a single citation box for ease of use We treat all requests as partial rather than full as a default so we don’t offer users the option to choose to request a full scan
• #17: Setting policy was challenging because we support 4 institutions across 12 branches Our goal was to enable as many types of user across the 4 institutions to be able to request as many items as possible across the collection We had a need to prevent that weren’t accessible (being mended, at bindery etc.) and items in a format that couldn’t be easily scanned (Audiovisual items, maps, rare books) from being requested (we did allow digitisation requests on microforms) We also had a requirement that certain users (Graduates, Public) couldn’t place digitisation requests Some branches were very small and didn’t have the resources to scan items so they were excluded too So despite starting with a principle of allowing as many users as possible to request scans of as much of the collection as possible we soon ended up with a wide range of exceptions
• #18: We decided against setting up a stand alone Digitisation Department in Alma but instead opted to enable each branch for digitisation that was capable of offering scanning services This meant staff in each branch could retrieve the item from the shelf, then scan and fill the request rather than having to ship it to a centralised Digitisation Department for processing This option has worked well for us and has help reduce lost time in sending items between branches
• #19: The number of exceptions we had in our policies came back to bite us when setting up our Fulfillment policies We had to specify each location we didn’t want to be available for digitisation (AV, Maps, Mending locations etc.) individually within the rules We also needed to specify which material types shouldn’t be available for digitisation (DVD, CD-ROM, etc.) seeing as we also interfiled AV items into our main book collections A bit of trial and error was involved in getting it right and not interfering with physical requesting was required but once it was set up we haven’t needed to make many adjustments
• #20: Digitisation requesting is similar to physical requesting in the positioning of the labels and the flow This is a screenshot of a book request. For a journal request there is an option to place a title level request as well as an item level request (the same as physical requesting)
• #21: Once the request has been placed it goes into the pick list at the branch that hold the item Staff can request both physical and digitisation requests from the shelves at the same time as part of the same workflow When items are scanned through returns or scan in items they are sent into the Digitzation workflow
• #22: The request then appears in the “Manage In Process Items” queue At this point we’d confirm there were no copyright issues and then scan the appropriate chapter/article
• #23: The scanned chapter/article is then attached to the request and submitted An email is sent to the user with the attachment There is a hard coded 10MB limit so if the attachment is larger than 10MB we have to supply it outside of Alma (either via email or a File Drop website)
• #24: Despite the problems we had getting up and running it has been a successful implementation There were some concerns that opening up digitisation requesting to a wide range of users would lead to us getting overrun with requests but that hasn’t been borne out in practice – most users are focused on accessing electronic resources and requesting a scan from a physical item is a secondary desire. So far we’ve been processing around 200 requests a month which is within manageable levels for us It’s now much easier for users to request scans than it was before – there are no longer a range of different forms to fill out and no need to enter user details into the forms Library staff workflows have changed as a result of the implementation with digitisation requests able to be picked up from the shelves alongside physical requests as part of the pick from shelf workflow The new workflows have led to the disestablishment of the specialist Distance team as most distance activity now happens within standard workflows All up it has been a worthwhile process and despite the pain endured within the testing and implementation phases the digitisation functionality is delivering the efficiencies we hoped it would
• #45: Sheffield was an Early Adopter of Alma, going live in June 2013. We have traditionally been a very request led service. We saw that Alma could allow us to advance our existing services and provide a platform for new services to be delivered in future.
• #46: As we were implementing Alma, we conducted functional reviews of potential new service and workflows in the new system. This included our existing digitisation on demand activity which is quite wide ranging across the library, the National Fairground Archives and the Special Collections and Archives.
• #47: The review quickly gathered that the range of digitisation activity would not readily fit into the initial Alma patron digitisation framework. Special Collections and NFA have lots of material not discoverable on Primo (from Alma); additionally the material listed in Primo may not be in a suitable condition to be digitised. It was also felt that the typical customer base includes many non-University (non-Library) one-time users.   Learning Resources Section requests for Eoffprints follow the requirements of the Copyright Licensing Agency’s agreement with the University which stipulate that requests must come from Module leaders only; must be linked to reading lists and comply with the reporting requirements of the CLA Licence - functionality currently not supported by Alma.
• #48: The outline of a viable pilot services was in place at an early stage, taking the patron digitisation request functionality and applying it to a pre-existing, though lesser-used scanning service, ‘myDocuments’ which was not available from the catalogue. A number of workflow challenges emerged from the review...
• #49: The gaps in the initial digitisation functionality in Alma were felt to be barriers to progress.  A number of specific issues were raised with Product Managers, and through Salesforce cases. A simple, unexplained checkbox which users have to actively select to differentiate Full from Partial digitisation. There was no indication of the service a user may expect, timescales, or any obligation to accept terms and conditions of service.
• #50: The ability to monitor and review approvals on digitisation requests is a challenging area. The ability for Patrons to request digitisation should be on the basis of individual need, not represented by course readings (for which UK institutions can obtain a Copyright Licencing Agency licence).
• #52: Improving the Patron Digitisation Request form to capture more specific extract data, and being able to control the flow of digitisation requests has been an ongoing process, working with Ex Libris. The enhanced Digitization Workflow rules allow automation of the workflow on a number of parameters, including: Copyrights Previously Approved - for cases where a similar request has been previously approved Number of Requests - checks if a required number of requests have already been processed Partial Digitization - Indicates digitization for part of a resource Patron Status - checks if the patron’s account is active or expired Publication Date - for records published before or after a given year Request Type - Indicates course related digitization, patron digitization, staff digitization, borrowing resource sharing digitization request, and lending resource sharing digitization request Time Span (In Calendar Years) - the number of calendar years since the creation date of the matched copyright record entries User Group - Which user groups are relevant for this rule