On Thu, 24 Aug 2000, Christa Easton wrote:

Christa,

Some random comments from my previous lives....

> the units that folks use, rather than a particular
> standard.  For example, for check in it might be "X pieces
> per hour with error rate at or below X."

When I managed serials in 2 small acad. medical libraries, it was
imperative to have the daily receipts out to users by 3PM or 4PM
each day. So, one measure was how often did I walk in and see a
pile of un-received journal issues from the day before (and
how long did they stay there).

I had also checked in myself enough to clock how long it
should take to do a day's batch and the average # of
checkins we did per day (given all issues received in the
mail were checked in in one day...heavy and light mail days.

So, indirectly I could assess if my serials checkin person was
spending too much time on check in (cutting into claiming and
other duties). In one setting we received mail twice a day, so
theoretically, it was possible to start checkin at 10AM and
continue until 4PM (not good when it usually took 2 hours to do
both batches). I found it motivated staff to keep the daily
deadline in mind rather than per piece.

The same was true for standing orders--we used to clear off
shipments received each week (1 truck per week of
monographic series, analytics, annuals, etc.)...usually to get
backed up in my office. :-)  Each item was processed and
evaluated per our internal policies (as CD officer I also
reviewed each volume) and if I had to return items to staff
because I didn't have the information I needed, or if after
receiving, Catloging had questions, I could assess how well staff
were paying attention to receiving/special instructions.

The only "number" there for me was 1 truck per week, clear off
each week's shipments. Some weeks we had a lot, others only 1
shelf full---but no backlog. But, it made the work week
predictable for them and myself.

I tended not to quantify very much, for example, with
errors--on those all too often days when I'd do checkin--that
was when I evaluated how controls were set up, were the dates
expected tweaked according to actual receipt dates, or were they
still set at the originals from 2 years earlier? If I or the
back-up person could breeze thru a day's batch with minimal
problems, I was satisfied that control records and checkins
etc. were set up correctly. If I was editing or having to spend
more time correcting when I substitued, well, feedback would be
given by way of a pile of issues when my assistant returned to
work. :-)

Periodic assessments like this, while not by design, gave me
valuable feedback throught out the year (and I came to realize I
had some gems working for me).

Other things I'd look for: how often were title changes missed
(issues ending up in a "problem pile" when they could have been
checked in), were special instructions overlooked? with Unicorn,
were checkins generated on schedule?

> I'm wrestling with claiming in particular.  Pure output
> does not seem like a good idea, since discretion can be
> the better part of valor in many cases.  If we set a turn
> around standard, we might run into trouble with vendors
> because some branches can be a bit...eager in their
> requests for claims.

I tended to look at resolution and follow-up, and timely
claiming. I used Sirsi reports to identify late issues every 2
weeks, but we claimed via email--small setting. I would want to
see the "issues to claim" list become smaller each run (meaning
issues were being received after that 1st claim. I did not
want to see huge 2nd claim and 3rd claim lists. I'd also watch to
see when my staff would decide a situation was urgent
vs. waiting for myself or the bindery asst. to say
so. Occasionally, I'd run late-issue reports to see what
was out there for a month and how often the same issue
showed up on subsequent reports.

Don't know if any of this is applicable to larger/different
settings, or where you have many people receiving.

Reeta

Reeta Sinha
Head, Serials Dept.
Hoover Institution Library
Stanford University
Stanford, CA
<rsinha@STANFORD.EDU>