[OPEN-ILS-GENERAL] ***SPAM*** Re: ***SPAM*** Holds fulfillment enhancement

[Mike Rylander]

On Wed, Jun 9, 2010 at 4:41 PM, James Fournie
<jfournie at sitka.bclibraries.ca> wrote:
> Hi everyone,
>
> There was some discussion about problems with holds fulfillment at the
> holds roundtable at EG2010.  I am pleased to share this patch with the
> community which has been thoroughly tested by the folks at
> Thompson-Nicola Regional District Library.  (thanks guys!)
>

Because it's nicely protected behind an OU setting and obviously
applicable to several in-use scenarios, I'll commit it as soon as I've
crafted a forward-port version for rel_1_6 and trunk.  I do have some
thoughts and best-practice concerns below, however, that I'd like
feedback on.

> Background:
>
> Evergreen's default out-of-the-box behaviour for holds fulfillment is
> a gas-saving method.  Holds are fulfilled by proximity.  In a
> multibranch library, holds are fulfilled at the local branch first.
> Many libraries, particularly single branch libraries may be ok with
> this, but it may be problematic for other libraries.
>
> Imagine a scenario where you have a large central branch and a small
> rural branch of the same library system.  At the large branch, there
> are many copies of Popular New DVD with lots of holds.   There are no
> copies at the rural branch.  Patrons at the small rural branch who
> want to pick up Popular New DVD at their home branch may never get
> their hold fulfilled because the copies will stay at the large branch
> as long as there are holds for pickup there.
>
> This patch adds an org unit setting that changes the opportunistic
> check-in so that items checked in will be assigned to holds by request
> date first, rather than proximity.   This setting can be applied to
> any level of the org tree, so in some situations you may even want to
> activate FIFO for large libraries, but leave the original setting for
> smaller libraries with less traffic who want to keep their copies more
> local.
>

I believe, in order to make sure that the behavior is sane and
expected, one would need to use hold boundaries
(action.hold_request.selection_depth) to try to keep holds as local as
possible.  AIUI, that is indeed what SITKA is doing -- restricting
holds to within geographic areas, or even to "systems", because of the
extreme geographic distribution (and costs of transiting therebetween)
of members by using hard hold boundaries.

Imagine Library A and Library B can share items.  At A, they have
"Holds: FIFO" set to true, but B does not.  They both have long, equal
hold lists (that keep growing) for similar sets of items.  All else
being equal, they have interleaved lists, where every other hold is
targeting a copy at the other library.

In this scenario, B will capture holds in non-fifo order and fill
local holds quickly, but A will send 1/2 of it's captures to B.  A
will be drained or resources, and B will keep everything it can
because both hold lists keep growing.

There are three ways out of this configuration-cause imbalance with
the code that exists today plus th attached patch, in general order of
increasing bluntness of fixing instrument (IMO):

 1) Soft hold boundaries at the appropriate "here-ness" level. Say,
"system".  This would make holds stay local on a hold-by-hold basis if
there is an available copy within the system.
 2) Everyone uses FIFO
 3) Hard boundaries set at the appropriate level -- what SITKA is doing (IIRC)

While the most heavy-handed, option 3 is actually ideal for some
situations (like SITKA, where transit costs are prohibitive, and
MCLS(? ... MLC) where the goal is effectively separate
mini-consortia), and actually suggests that an all-or-nothing within
an effective resource-sharing OU set is the initial best-practice we
should document.

Thoughts on that stuff?

Thanks, James!

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com