I have been doing a bunch of work in reviewing workflows and implementing new or changes to existing workflows, especially in Technical Services. In the process, I have been asked not only about the process I went through, but the rationale and value in doing such an exercise, especially for organizations where most Technical Services work has been outsourced. So just thought I’d jot down some thoughts.
What is Technical Services?
As part of the review process, I visited a number of libraries’ Technical Services (TS) department, and I was somewhat surprised at how varied they were in terms of what areas are included.
May or may not be included:
- InterLibrary Loans (ILL)
When these functional areas were not in TS, they would typically be in the circulation/borrowing department. On the rare occasion, some of these parts might be their own department (e.g. acquisitions + collections).
Level of Outsourcing
In recently years, more and more technical services functions are being outsourced to vendors. There are definitely advantages and disadvantages to both outsourcing and doing it all in-house. Nevertheless, it’s not all or nothing, with a large range of how much is outsourced.
What I find interesting is that some people are dead set against outsourcing and yet, a lot of material is ordered using an ARP (automatic release plan), where a vendor chooses for the library or everything meeting specific criteria from the vendor is purchased. So almost all libraries have some level of outsourcing even though it might be a small amount.
My stance has always been about the effects on service. Sometimes outsourcing gives libraries a great advantage. Pre-processed and catalogued material usually means it can get to the shelf faster. Other times, the quality of what the vendors offer is below the threshold of what an organization would accept or want.
Quality of processing is easier to notice and check for, whereas quality assurance of cataloguing is more difficult. Cataloguing quality also seems to vary more widely, and if libraries are concerned with good metadata (which they should be(!) since it affects searchability and browsability within the catalogue), then doing it in-house or at a corsortium level is often better than relying on a vendor. In some cases, the amount or availability of resources may be another reason to purchase records, especially for more specialized material or material where catalogue records are more difficult to find, such as multilingual or video games.
Rationale: The Why
All the departments I spoke to and even our own library has a working Technical Services department, so why do a workflow review?
Much like the discussion on how the focus of libraries is moving from collections and reference to community space and programming, I believe that TS is dealing with much more digital as opposed to print material, and the work is shifting to more quality assurance and more intellectual work with much less rote work since much of that is being outsourced or can be done more efficiently.
Technology has also improved over the years, such that some of the work can be automated or semi-automated, and generally allows work to be done more efficiently.
The problem is that most departments (TS or otherwise) do not have a review plan, where workflow is reviewed every X number of years. Too often, people think:
if it’s not broken, why change it?
While that’s true, never changing the department means not making the best use of resources, technology, and the skills that are newly learned or from new graduates.
How a review is done can vary widely depending obviously on the organizations and the goals of the review. Most departments will also have some idea of where they need improvement, but honestly, when I started the work, I had very little idea of what the process involved and where improvements might be made.
Much of the work was information gathering, which involved:
- interviewing staff, and asking follow up questions
- visiting other libraries and speaking with managers/supervisors particularly around workflow and how issues are resolved
- mapping workflows
In the first half of my workflow and productivity presentation from last year, I talked about the various methods I used to map the workflows in the organization and the methods I used to review and build proposed new workflows.
I prepared a short term plan (with a timeline up to 12 months) with staff in mind. It consisted of a few sections:
- A list and acknowledgement of the many improvements already made.
- New Proposed Process
- List of Changes in Duties by Position
- Implementation Timeline including training and transfer of duties
- Review Schedule (in terms of reviewing how changes and new workflow is going)
Side note: I also wrote a long term plan that was more in the 2-5 years range, but it was fairly specific to the organization’s circumstances and was therefore written solely for management. At the time, I expected it to be a “this is what I think based on current information, but we would need to review the plan again in 2-3 years and make sure it still makes sense” kind of plan. As a result, I never implemented it, and the plan didn’t have anywhere near the detail the short term plan did, especially around implementation.
After preparing the plan, I took it to management for review. They had some comments, especially around wording and implementation details, but otherwise it was fairly unchanged.
The next step was to present it to the staff. I set up two meetings specifically for this one step. The first meeting was simply to process and the plan, with a meeting a week later when we discussed the plan including any changes. The purpose was to give them ample time to look it over and think about it. The proposal meant major changes in the department, and I didn’t want staff to be rushed, but to have the opportunity to bring thoughtful comments and discussion.
We also made some adjustments to the timeline because it turned out staff had already done some of the tasks before, so it would be more review than completely new duties. As such, we rearranged a few things, putting those they were familiar with earlier in the timeline, and moving some other things later.
Once the plan was settled on, we began implementation.
I would like to think it went smoothly. Staff were happy to have a plan they could refer to, and a step by step timeline with the assurance that we could push the timeline down as needed. They also appreciated that the changes were done incrementally (as much as possible) so that they could get used to changes slowly instead of all at once.
We generally kept to the timeline with only minor changes. There was also one section of the plan that we decided not to implement, partially due to the logistics of switching things over and all the changes coming up due to the renovations. We decided to put it off until later, but something we would definitely revisit.
As a result of the changes, we benefited a great deal from all the changes:
- more streamlined workflow,
- less physical movement of items,
- better use of physical space,
- better and easier tracking of items,
- staff broadening their skills and knowledge,
- staff duties more aligned to their classes,
- staff and department can broaden their portfolio of work,
- moving towards centralizing TS-related work into the department, and
- greatly improved turnaround time.
Doing a workflow review is a great way to improve productivity and efficiency. While in this case, changes obviously needed to be made, if it has been a number of years since anyone did a review, consider taking time to do a review. You might be able to integrate changes in technology, or cataloguing/authority control, or new skills and knowledge.
Even when a lot of the work is outsourced to a vendor, there may be improvements to be made in handling what work is done in-house.