[685] in ad-lib
Re: workflow problems--I mean, opportunites
daemon@ATHENA.MIT.EDU (Sarah Mitchell)
Wed May 24 16:56:01 1995
To: rschmidt@MIT.EDU
Cc: ad-cat@MIT.EDU
In-Reply-To: Your message of "Tue, 23 May 1995 12:50:47 EDT."
<9505231650.AA11147@lauren.MIT.EDU>
Date: Wed, 24 May 1995 16:55:31 EDT
From: Sarah Mitchell <smitchel@MIT.EDU>
Ray,
I think your idea about the computer disk envelopes makes sense.
We'll pass it along to Charlene.
QC Procedures:
We talked at BOG today about barcode misreads and I pass it along as
further background for your suggestion. Grant isn't sure what happens
to barcode misreads on Geac Advance. He knows that the system does
a check for 14 characters, but, isn't sure that they verify the
accuracy of the barcode through the check digit. We also don't know
wether the system generates any kind of print report. From something
Michel Ridgeway said a long while back, I don't think it does. We
need to test a variety of bad barcode reads.
I think we should start out on the conservative side when it comes to
making sure that records have made it into the main database. I don't
know whether its as big an issue with ftp, but, I certainly have heard
of data corruption in moving large records into a local system via
Passport.
Your suggestion about doing an extended search on each item cataloged
gives me some initial concern for the very reason you mention.
However, I like the idea that we could do away with card production,
sorting, and filing. Were you envisioning that at the end of the
extended search that the cataloger would 'refile' the records to
identify MARC table errors?
System status: another topic that we talked about at BOG today. Geac
Advance has the ability to automagically change the status. Grant has
a general idea of how this works, but, we concluded that we needed a
subgroup of staff from bindery, acquisitions, cataloging, and
processing to investigate the Advance capabilities and the other
workflow questions involved.
Cataloging instructions: Hopefully, the demo tomorrow will be
illuminating on what the serials check-in process is like.
Thanks for giving us a jump start to thinking about workflow
implications.
More on this tomorrow...
--Sarah
>Sarah--
>
>After the library-wide meeting on Advance yesterday, and
>your e-mail last week about standing orders, I have some
>comments on workflow in 4 areas: barcoding computer
>disks; reconfiguring quality control procedures for
>monograph catalogers; tracking items in the bindery
>backlog; standing order procedures.
>
>BARCODING COMPUTER DISKS
>
>A few months back I talked with David Murphy about what
>Barker does with 3.5" computer disks that arrive in the backs
>of books in plastic sleeves attached to the books, without an
>envelope of their own. Since they keep the disks at the Circ
>desk, David said that they keep a stock of disk-sized
>envelopes for storing them. On this envelope they attach a
>copyright warning, a call number label provided by the
>cataloger, and the disk's barcode (which has been cut out
>and paper-clipped somewhere inside the book by the
>cataloger). I think they property stamp the envelope too.
>
>I imagine the procedure is very similar in other libraries. It
>seems like it would be a good idea for SAS to get some of
>these envelopes so that they don't have to mess with
>scissors and paper clips when barcoding books
>accompanied by disks. Instead we could treat them in the
>way we treat 5 3/4" disks. Having the envelope at this point
>in the workflow would also give us a better place for the
>initial location/property stamp, rather than stamping the disk
>(this is better for the disk). It would also be a better place for
>catalogers to put the call number, rather than affixing a label
>somewhere to the paperwork or book for later attachment by
>a processing librarian.
>
>QC PROCEDURES FOR MONOGRAPH CATALOGERS
>
>Barcoding on receipt means that monograph catalogers
>won't be placing barcodes on printed order slips for a 4-week
>retention in case of GOCIRC problems anymore. I assume
>in Advance we will know in 24 hours if a record didn't enter
>the main database. But when a barcode misread occurs
>during cataloging, for instance, what means will we have for
>determining the correct barcode number?
>
>I have one suggestion for solving this, which at first glance
>may seem to slow things down but may in fact do away with
>a number of other steps in the cataloging process. It is as
>follows:
>1) After producing a record in OCLC the cataloger retains
>the book till the following morning.
>2) In Advance (the following morning), wand in the barcode
>to call up the record.
>3) Extend search choosing call number; examine online
>"shelflist" for conflicts.lf all is in order, send book on to the
>bindery.
>
>This procedure will improve quality control and problem
>resolution (the current procedures were already
>improvements over old card receipt procedures), by doing
>several things:
>
>1) Determining that the cataloger actually produced the
>record in OCLC; catalogers currently count shelflist cards
>daily, matching them against statistics to make sure the
>cataloger hasn't accidentally sent the book on without hitting
>the "produce" button.
>2) Eliminating the need to file shelflist cards, which is now
>done only to prevent call number conflicts. When a conflict
>occurs, the book is in hand and can be easily corrected.
>Currently, when conflicts occur, catalogers have to retrieve
>books from the bindery or divisional/branch library.
>3) Eliminating the need to sort and distribute shelflist cards.
>4) Identifying problems analogous to old GOCIRC problems
>at a point in which the cataloger will still have complete
>information to provide to the database maintenance staff if
>necessary.
>
>
>BINDERY BACKLOG
>
>With overnight ftp-ing of OCLC records into Advance, we
>need to account for the time between cataloging a record
>and the item's stay in the bindery. Is there a need for
>temporary location information, to be updated on receipt by
>processing librarians in public service units?
>
>STANDING ORDERS
>
>Placing cataloging instructions for monograph standing
>orders online. Just so we're clear on this, I think the only
>instruction to catalogers on the xeroxed manual kardex is a
>classed together call number, when there is one. This
>information is also provided to us in the manual series
>authority file, but in terms of workflow, it's more efficient
>when it comes to us on the xeroxed kardex. There may be a
>parallel as we move to an online environment: while a
>classed together call number is appropriate information to
>include on a series authority record, it may be more efficient
>to include call number information on whatever the online
>version of the kardex is. I'll leave this suggestion short and
>vague, since I don't know what monograph standing order
>check-in will look like in Advance.
>
>--Ray Schmidt
