Acquisitions - introduce the idea of 'states'
To enable the Acquisitions Library Review process to support more complex workflows, it could be extremely useful to introduce the idea of 'states' (or similar) to lists under Review. Customers could select how many 'states' their workflow necessitates and what labels they wish to attach to 'State 1', 'State 2' and so on (e.g. 'Liaison Librarian review', 'Link checking', 'Acquisitions processing' etc). Lists submitted for review could arrive in 'State 1' and then be moved to 'State 2', 'State 3' as this review process progresses. The view of lists under Review could then be filtered according to State (e.g. 'Show me all the lists under Review currently assigned to the Acquisitions team). Rather than the current Review process (Submitted for, Under review, Completed), the concept of states would allow customers to devise a richer workflow which mapped to local requirements without requiring Talis to build prescriptive review workflows.
To enable reporting on the Reviews process (to support Library KPIs and the like) this could be tied to a reporting schema which identified the total processing time of a list under review and the amount of time a list took to pass through each State.
In addition, some additional permissions settings could make Acquisitions permissions more granular in nature (by associating Acq permissions with particular States).
Adminchrisc (Admin, Talis) commented
Hi Richard and Georgina,
Two things. I have changed the terminology from "state" to "stage" in the story definition. I think the original "state" terminology was too close to the existing fixed review statuses (Requested, In Progress, Complete) we have in the system and could have been confusing.
I think "stage" better represents what we are trying to model here, i.e. the status (or state) of the review remains "In Progress" but it needs to pass through a number of tenant-defined stages (e.g. at digitisation, with acquisitions team, etc...) before it can be considered complete.
Onto the assigning a user - We are currently in progress with an "Assign list owner" story (XIP-2190). This will put in place the necessary dialogues and facilities to search for people and assign them as the owner of a list.
This is essentially the same functionality as setting an assignee for a review. So, instead of bundling that functionality into the "stages" story (which is close to being picked up), I have added a new story (XIP-2226) on the stack. We will let XIP-2190 and the stages story complete naturally, then the addition of assignees should be a logical and easy extension.
The story description is as follows:
In a similar way to XIP-2190, a user can be assigned to any review "in progress".
The assignment and search works in the same way as XIP-2190 (search and auto suggest).
From the all reviews screen, there is a new column "Assigned to". This column includes the name of the user currently assigned to the review. The column is sortable.
From the top of the all reviews screen the user can filter the table on "Assigned/Unassigned reviews" (i.e. reviews with, or without, an assigned user.
Georgina Parsons commented
Thanks for the update and we're very excited about this!
Firstly, I'll add my support to Richard's addition of the "assignment" aspect.
My other obsession is reports as it's what I spend too much of my time doing! They weren't mentioned, but will the 'states' (and assignments) be added to the All Reviews report in Aspire? Can this report be filterable by these? (Sort is okay, but filter is much easier to handle.)
You could then continue that thought process along the line of pre-filtered reports by role, whether or not the idea of assignments and reports by user will work (it's a usual intermediate report for seeing how many lists are with acquisitions and how many are with subject librarians).
E.g. Lib Acq staff have a reviews report which shows them everything in their state, and Subject Librarians (if they have their own Role) have a report of everything that needs progressing by them. Of course, by individual user, with alerts when a list is assigned to them, would be amazing too... I'll stop now I'm getting idealistic and mentioning alerts!
Oh, but can you remind me about reporting on length of time in process? I thought we'd been advised originally that we could do this with reviewed lists but I can't see how. We'll need to know the average time a list spent in each phase of the review, so we can see which part is the most time-consuming and improve our processes or train more or plan better around that. Will that be reportable on?
Richard Cross commented
Hi Chris - thanks for the update. Great to see this being progressedl I appreciate that 'states' functionality might well be rolled out in phases, but the (for us) critical component not described in that developer outline is *assignment* (i.e. the ability to see in state N that six lists have not been picked up by any staff member, 3 are with Librarian Smith and 2 with Librarian Patel). This functionality would require that someone looking at a list in state N could accept *assignment* of that list (and, the option to unassign it, or have it unassigned). The assignment need not have any additional permissions implications, but it means that a team working on state N lists can immediately see what lists are actively being worked on and which need picking up.
Adminchrisc (Admin, Talis) commented
I just wanted to share the story description I have sent to the developers, to make sure we implement this as expected:
Every acquisition review with status of "Started" can also optionally have a "state" assigned with it.
States are configured at the tenancy level and therefore can be different for each tenant.
Optionally a default state can also be configured.
Setting a state
When a review is initially started, if a default state is set in tenancy config, the review automatically assumes the default state.
From hereon in, the user can change the state of any in progress review using a drop down at the top of the list review screen. The state can be unset completely if the user selects the empty value in the drop down. Whilst the state is being saved (following the user selecting a new value) a progress spinny is shown to the right of the state drop down.
Creating data to allow reporting at a later date
This story also introduces the notion of events for reviews. This allows us to report on time spent in status/state at a later date. The events feed works in the same way as list/tenancy events in the existing codebase and uses the same data model.
Every time a state is set or changed, including when the state is set via the defaulting process, an event is written to the /events log in the review.
Georgina Parsons commented
Wholelheartedly support this. We're not finding the review process sufficient as we very much have a collaborative approach to lists which is where Aspire is very good but not quite perfect. For example we ask academics to request a review when they've completed a list, and this first needs to be reviewed by the acquisitions team. When they've made the relevant checks/edits/decisions, the subject librarian needs to complete the review to sign off or confirm orders etc. There's no way to do this now:
- if the acquisitions team marks the review complete when they've finished their part (so they know not to keep working on that list) the review information is lost (notably student numbers which the SLL needs - separate Idea, please vote!) and the SLL can't edit the log
- if the acquisition team just ask the SLL to complete the review, there's no way of flagging that list as 'not to work on' due to the lack of (a) states or (b) a list-level note.
- if the acquisition team mark the review complete then request a new review of the list, there's no way of submitting that review to the SLL as the review just goes to the administrator, you can't choose who it goes to.
We're open to solutions to this problem, but I think the 'states' idea as well as a list-level review note (and the retention of review information) would work for us.
Richard Cross commented
Two additional functional enhancements identified during discussions of this idea:
1) List level notes - in addition to Item level notes, the ability to replicate similar functionality at the list level would be extremely useful. With similar free-text dialogue functionality to the Item level, this would allow access to information about a list under review without requiring someone to scan or investigate each individual item. A use case for this? Someone switching a list to a new state wants to provide list-level information to the team about to pick up the list in its new state.
2) 'Accepted by': When a list in a particular 'state' is picked up by a team member, they should have the option to scan through the list and then optionally 'accept it'. This means that, in the all-lists-in-the-state review the display could show that 'Joanne Bloggs' has accepted that list and is working on. This would mean that all team members with responsibility for a particular 'state' could not only distinguish which lists had been picked up and were being worked on, but also by whom. There should also be an 'unaccept' option to free up a list, and acceptance associations should be cleared when the state of a list is changed (so that there is no acceptance indicator for a list entering a new state). It probably makes sense that an acceptance indicator does not preclude others from accessing, reviewing and actioning a list (and maybe even allowing them to claim acceptance from the other staff member).
Together, these two enhancements would support (a) a list level dialogue about the progress of a list review; (b) a clear indicator of which lists in a list-of-lists were being worked on at any one time, in whichever state, and by whom.
Annette Moore commented
I think the concept of 'states' would be useful. Although much of the review work at Sussex happens within one team and one person follows through on most steps in the review process, it would be useful to be able to mark lists as 'New Course' or 'In Query' status if the lists were likely to be very expensive to purchase all items to our agreed ratio. Such lists could then be marked for the attention of a senior member of the team.
University of Sussex