[OPEN-ILS-GENERAL] Fulfillment Prioritization

[Mike Rylander]

On Mon, Mar 12, 2012 at 8:34 AM, Thomas Berezansky <tsbere at mvlc.org> wrote:
> I think you have the "hijack" backwards. You are assuming that an in transit
> hold will be hijacked and pulled back to the home library. In fact, the only
> "hijacked" transits will be "Patron A has a hold with a copy in transit, we
> will ignore the in transit copy and put this copy we are checking in on the
> shelf for them *right now* instead, pushing the transiting copy off of the
> hold". No patron will get a copy that was going to a different patron as a
> result.
>
> It looks like most of your other concerns on this stem from that initial
> misunderstanding, though you are correct that things may go right back into
> transit when they show up. That is no different than if a hold is canceled
> while in transit, though.
>

So that we're all using the same terms, I'll offer some definitions
for the context of the discussion:

  * A "useful" hold transit is one that ends with an item on a hold shelf
  * A "useless" hold transit is one that ends in another transit --
either to fill a different remote hold or a return transit

The problem, from the PINES perspective IIUC, is increasing "useless" transits.

The is that a "useless" transit costs on average twice what a "useful"
one does, both in terms of the time of the item being completely
unavailable to anyone, and in money spent by the library.  On the
other hand, a "useful" transit costs the patron some amount of time
waiting for their item to arrive.  So the balance that must be struck
is to reduce the cost to both parties as much as possible to some
minimum.  From an objective point of view in a PINES-like environment,
because there is a monetary cost to "useless" transits, the importance
of reducing these is greater than the importance of reducing the wait
time for the patron, and hold hijacking would tend increase the number
(and aggregate cost) of "useless" transits.

[NOTE: This is an over-simplification of reality for the sake of
argument.  For PINES, there may be no direct monetary cost for each
"useless" transits, but there can be significant costs down the road
at courier contract renewal if the load caused by newly "useless"
transits makes the total volume increase well beyond the
purely-"useful" transit load.]

The inverse, of course, could be true for an organization with fixed
courier costs, or extremely low per-transit costs.  For them the
opportunity costs in terms of patron service may be measurably higher
than the monetary and unavailability costs to the library.  In that
case this feature would be useful.

IMO, assuming my analysis is sound and given the structural
differences required to make one or the other of the above true, I'd
suggest that this would need to be a bit more complex than outlined
above, and because of that it should be controlled by an Org Setting
instead of "circ staff choice".  The added complexity would be to only
hijack holds when the transiting copy is coming from a particular
subset of the org hierarchy.  For an Evergreen instance in use by a
single library system that wants hijacking across the board, this
would be the top of the org tree, of course.  But, for a PINES-like
installation, it might be set up to allow this only within a single
regional system where, for instance, they have an internal courier
system that has no per-transit costs and does daily intra-system
delivery.  This is partially suggested by the "only hijack with
locally-owned copies", but I would go further and say that the transit
source and destination should play a role as well, because it's not
really the copy we're concerned with, but the cost of making a useful
transit useless (though the copy's ownership is something that's
useful to consider, especially politically).

Make sense?

-- 
Mike Rylander
 | Director of Research and Development
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com

>
> Thomas Berezansky
> Merrimack Valley Library Consortium
>
>
> Quoting "Hardy, Elaine" <ehardy at georgialibraries.org>:
>
>> Thomas,
>>
>> While improving the hold fulfillment along these lines would be helpful
>> for our patrons and staff, I do see some problems with the idea to
>> "hijack" an in transit item to fulfill the hold. While these issues won't
>> necessarily occur if there are plenty of copies of a title within a
>> consortium, I do see them occurring for those titles with few copies in
>> the consortium. The problems I outline below would be if there are no
>> copies in the local system for the original hold to fulfill and a hold for
>> a patron at the owning library hijacks it after it is received at the
>> original hold library.
>>
>> A lot of patrons monitor their holds, especially if it is an item they
>> need by a certain date or just really want to read. If suddenly a copy
>> that was in transit to them is back to waiting for a copy, I see unhappy
>> patrons. Unhappy patrons that the front desk staff would need to deal
>> with, without understanding themselves why it happened. I can see staff
>> adding to the unhappiness if they let the patron know they saw the item
>> come through and it went right back out.
>>
>> Another potential problem is increased costs in courier service, depending
>> on how a library pays for that service. We pay per pickup, but if someone
>> pays per package, immediately sending an in transit item back out might
>> add costs. Although other changes that would make the local copy more
>> likely to be trapped would decrease costs and might balance this. It is
>> also going to increase staff time when they have to repackage the item to
>> send it back out for what they would see as no  reason.
>>
>> Another potential problem, at least in PINES, is that it could increase
>> the amount of time all holds on an item would take to be filled as well as
>> that individual hold by the local patron. It is very possible that the
>> "hijacked" item takes another week or longer to make it back to the local
>> patron, where an item at a nearby, out of system, library would be there
>> faster. For us, this is because of the time it can take to get from branch
>> to central, where the statewide courier picks it up and then the time on
>> the other end from central library to branch. Some systems can only afford
>> once a week pickup at their branches. So, even when the courier delivers
>> from central library to central library within days, another two weeks can
>> be added to transit times because of local issues.
>>
>> As I re-read your steps, how you are thinking of the design may make some
>> of the above not occur (if you mean that if there is no local item at the
>> holding library, the item will stay to fulfill that hold before it returns
>> to the owning library) but I just wanted to make sure you've considered
>> them.
>>
>> Elaine
>>
>>
>> J. Elaine Hardy
>> PINES Bibliographic Projects and Metadata Manager
>> Georgia Public Library Service,
>> A Unit of the University System of Georgia
>> 1800 Century Place, Suite 150
>> Atlanta, Ga. 30345-4304
>> 404.235-7128
>> 404.235-7201, fax
>>
>> ehardy at georgialibraries.org
>> www.georgialibraries.org
>> http://www.georgialibraries.org/pines/
>>
>>
>> -----Original Message-----
>> From: open-ils-general-bounces at list.georgialibraries.org
>> [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of
>> Thomas Berezansky
>> Sent: Friday, March 09, 2012 5:04 PM
>> To: Evergreen Discussion Group
>> Subject: [OPEN-ILS-GENERAL] Fulfillment Prioritization
>>
>> There is a desire for copies to fill local holds before going into
>> transit, even when there are already copies in transit. This would result
>> in copies showing up to fill holds that are already filled, but would also
>> allow for holds to go to the hold shelf faster when a copy is already
>> right there.
>>
>> I have worked out the following thoughts for this, but would like more
>> opinions before work is started on it.
>>
>> The general idea would be to add a new Org Unit setting to control the
>> behavior. When enabled copies returned to the library would:
>>
>> 1 - Look for non-captured holds at the current location. If any exist,
>> capture for them and move on to the hold shelf.
>> 2 - Look for captured but in transit holds at the current location. If any
>> exist, "hijack" that hold and move on to the hold shelf. The original copy
>> will remain in transit.
>> 3 - Resume all other holds/transit/reshelving/etc code normally.
>>
>> This may require teaching the hold targeter to update the list of copies
>> *without* wiping the captured state of in-transit holds, perhaps with a
>> special parameter passed in. That parameter may be best supplied when
>> doing the "Retarget Local Holds" checkin modifier work, rather than as
>> part of normal hold targeting. Especially if the first additional
>> limitation below is included.
>>
>> I am thinking that there may need to be additional limitations, for sanity
>> purposes, but am not sure about them:
>>
>> 1 - Limit to copies owned by the library that the checkin is happening at.
>>
>> This would basically prioritize local copies as filling local holds, but
>> would not prevent someone else's copy from transiting. That transit may
>> even be back to their own library.
>>
>> 2 - Not run the code if capturing local holds as transits.
>>
>> Because otherwise you may just be displacing things that are intentionally
>> in a limbo-transit state.
>>
>> 3 - Require a checkin modifier be active, which may remove the need for
>> YAOUS.
>>
>> If replacing the YAOUS then this would allow for per-workstation
>> decisions. If alongside the YAOUS then the YAOUS being disabled could be
>> used to hide the checkin modifier outright. Either way SIP may need to be
>> taught how to (optionally) enable this modifier.
>>
>> 4 - In the event of a Force or Recall hold being in the stack, *never*
>> fill a different hold instead.
>>
>> These are copy level "force cut in line because we have a really good
>> reason" holds in Master/2.2, and I don't think we should avoid transiting
>> to fill them.
>>
>> Thomas Berezansky
>> Merrimack Valley Library Consortium
>>
>>
>>
>>
>>
>