Originally at Lehigh we really wanted to make OLE really special by integrating in some concepts we learned from our front line practitioners. And building in the functionality piecemeal wasn’t going anywhere so we decided that a more holistic solution was needed. Our understanding of library workflows is that our staff create workflows around “objects” that reflect their daily work. These include:
-Tasks and Chores
And these tasks are often easily divided up into categories/queues so that they are neatly organized.
You may notice that that very short list doesn’t include bib records, invoices, receipts, purchase orders, etc. Those types of docs remain important to the task at hand, but they are merely associated with it rather than being the central focus. And tracking each step of the process (and identifying the beginning and ending points) are what keep people on task and help give a strategic overview of what is being done.
Our proposal was to make OLE revolutionary by including a task/request-based workflow management system that was directly integrated with the ILS itself, rather than a standalone system. We wanted it to be flexible, extensible, and customizable in a way that reflected the differences between libraries, so each and every library could customize the layout and hierarchies that defined their workflows. There was also a focus on the design so that it kept communication to patrons (or other staff) as an integral part of the process (rather than an afterthought) and that statistics should be built into the process as part of evaluating the workflow setup.
This has several benefits:
-Manager oversight over tasks/projects
-Enhances patron communication and relations
-Intuitively allows users to see the progress and flow of their work
-Prevents losing track of work
-Directly links the tasks with the relevant library docs/data
-Standardizes evaluation of workflow progress
The “core” spec we wrote expresses this overarching idea that a flexible and extensible system is good for library workflows: https://docs.google.com/document/d/1WHuXS38S9QRbawBsc7zMI6ZT47kdwqHYKC-HuIOm0dQ/edit?usp=sharing
And even if we weren’t able to build something more forward thinking, we came up with additional specs that would give us some of that functionality, but focused on several of the more labor/tracking intensive tasks in the library:
Usage Case 1/Additional Spec: https://docs.google.com/document/d/1XFJAzfqMsV1l4vvdNGE-UilQf94zey6DiSfsm3GUGoU/edit
Usage Case 2/Additional Spec: https://docs.google.com/document/d/19dqOuKV-Dv-JYRuxB0-DYOl0uEgDReqVvtBCG0hIOvo/edit?usp=sharing
A lot of this thinking was greatly influenced by our implementation of the GIST addon (created by a dev team at SUNY Geneseo) into our ILLiad self-hosted installation. In a sense this was a “proof of concept” that a queue/task/request based workflow management system could be extensible enough to greatly enhance a workflow for which it had not been designed (details in the first Google Doc).