UNICORN CONSORTIA SIG 2006
RECOMMENDATIONS FOR SIRSI
SEPTEMBER 28-29, 2006
DES PLAINES PUBLIC LIBRARY
General concern: What has Sirsi accomplished from last year’s list? A status report is requested from Sirsi as part of their response this year.
Customer Service and Communication:
*Communication (or lack thereof) between Sirsi sales staff and consortia about member libraries who are shopping:
Should there be a protocol? While recognizing potential issues such as confidentiality and restraint of trade, the SIG requests a statement of policy and protocol from Sirsi; and that consortial offices be apprised of any developments or proposals that would affect consortial operations. This includes a whole system or simply a product the consortium would have to support and manage. It applies to both responses from Sirsi to requests for information from customers and proactive communications initiated by Sirsi.
*Upgrade support (not purely a consortial issue but…):
The SIG requests:
*A way to provide accurate stamp.dat information in advance of a server upgrade so the appropriate client can be loaded in advance and without impacting network bandwidth
*A way to make selective enabling of client stations to upgrade on a more granular level than by library, so each library can upgrade a few critical stations
initially rather than making one library have to wait till last
*Administrative privileges needed on PC to do an upgrade: a) a warning at the front end of the upgrade that admin privileges are needed when they are; b) if admin privileges are required, don’t exit the upgrade with an error BEFORE ANYTHING ELSE IS DONE if a non-admin user runs it; and c) notification at the end of the upgrade process when the upgrade attempt has failed because of the lack of admin privileges
*To protect against transmission errors or interruptions, all files should be verified before they are installed to complete the upgrade.
*The server should be able to query and validate the client level .
*7 x 24 upgrade support should be part of Critical Care with at least someone from Client Care on call subject to sufficient advance scheduling, or an explanation of why this is not possible is requested.
*Please evaluate and review the quality of Critical Care phone response including the answering setup.
*These requests include installations performed by the customer and by Sirsi (especially Oracle).
*We can’t have Oracle upgrades done during online hours per current Sirsi practice, too much compromise of service to our constituents.
*Clarification of responsibility for embedded Oracle upgrades is needed; the license says the customer (library/consortium) is not responsible.
*Client Care needs better knowledge of whether a site is full or embedded Oracle.
*Client Care needs a better command and understanding of Oracle on a Linux platform. *Installers should leave checklists of what they did.
*Please disseminate Terry’s recent document delineating the different varieties of support to the SIG or provide the URL.
General Customer Care Responses and Actions:
*Please don’t send or refer us to help documentation.
*Tracking issues; incident summaries are sometimes incomplete.
*Too much “we are still working on this.” Please provide more details (activities, time frame).
*Calls are sometimes closed too quickly.
*Please pursue the promised follow-up dialogue from the March Client Care focus group in Nashville with designated contacts George Christian and Eileen Palmer. (I gave Terry the notes from that meeting.)
*Better inter-team communication is needed.
*Teams should be fully staffed.
*We need to be informed about new team leaders and other significant changes.
*A site is constantly told to upgrade even though Sirsi supports their version. This site also has the age old problem that they have done INITIAL trouble shooting and yet Sirsi doesn’t understand this.
New module implementation:
*We need better set-up help without extra charges.
*Implementation managers need to be more cognizant of consortium and generalI implementation (vs. configuration) issues.
Documentation:
*Please provide more information about the consequences of the configuration
options and recommended actions.
*We need improved patch description and more proactive distribution. We also want to commend Sirsi on the progress with patch management.
FRBR:
We request the promised follow-up and clarification of status.
Normative Data Project:
Please provide the status of consortium level access.
General Software Issues:
*Don’t break it when you fix it!
*Please provide a status report on automated testing, especially in a consortial environment.
*Please provide a status report on load simulation testing.
*Please do more usability testing with novices vs. experienced system users.
*How are the development resources being distributed between Horizon and Unicorn? Has there been a shift in resources? We also want to commend Sirsi on the QA for GL3.1 based on early implementations.
Specific Software Issues:
Closed Dates limit is way too low (approximately 1,000 dates). Most thought that it was 64 dates per library and not 1000 total. There were three suggestions:
*Document and clarify the actual limits, per library and total, and the impact on the system of exceeding them.
*Increase the total if it’s only around 1000; this is not enough for a large consortium.
*Fix the current bug so that overflow does not harm system performance. There should also be a warning to stop an operator from exceeding the capacity, especially if it will hurt.
Standalone/Offline (Mostly) Consortial Concerns:
The SIG requests:
*Improvements to Not At Home checkins so that the products are usable in a consortium for checkins
*All transactions should succeed (please verify that this is now the case and as of what release level).
*Items should not be put into Transit.
*The software should not be treating these transactions as interactive in the way that online transactions are.
*It must be possible to sort transactions in a load by individual library.
*There should be an alert on a client station when an upload is starting and when it ends.
*Similar concerns apply to PocketCirc.
Concerns from The Library Connection followed by SIG comments:
1) Display of Erroneous Call Numbers in Group Scope
When doing item searches in iBistro from within a library that has branches (using the group scope to search the library and its branches), the search results screen will display the call number associated with the first library in the consortium to have attached a copy to that item record. Generally this is not the library one is searching in. The next screen, the detail screen, does display the correct call number. However, most patrons stop at the search result screen, go to the wrong shelf location, and end their search frustrated that they cannot find an item the catalog claimed was on the shelf.
Sirsi’s response to this issue is the suggestion not to display the call number. Most of our libraries with branches feel this is an inadequate response.
This behavior was apparent in WebCat, and carried over to iBistro. We understand it continues in EPS. It is a real sore spot for Library Connection.
(SIG: We request that this be made more location-driven; that no call number display if the station library does not hold any copies; and that Sirsi inform us if and how this is fixed in EPS.)
2) Showing Shadowed Copies
Shadowing seems to be unworkable in a consortia setting. Shadowing should conceal copies completely from patron searches. However, we have found that if another library in the consortium owns a copy of the item, then the shadowed copy appears in the search results screen of the library that shadowed the item with the notation “unavailable for display”. Worse, the patron can click on this item and move to the next screen, where full details appear along with the notation “no copies available in any library” on the copy info and “Volume not found in Library” for item locations and call numbers.
We are a large enough consortia that one or two libraries a year move to smaller locations while their buildings are renovated. Books in storage are shadowed, but patrons can still find them in iBistro. Another contributor to the problem are books marked for discard (this is a shadowed location), waiting for a monthly discard that will gather discard statistics.
Sirsi’s response to this issue is to suggest graying out the display or changing the message. We would rather have shadowed work for consortia the way it works for individual libraries.
(SIG: We wish to convey this request with concern.)
3) Inability to Remove Copies if other copy is under Serials Control
A library cannot remove a copy if another library has a copy of that item under serials control. One of our members is an academic library and has many items under serials control that the public libraries do not. Even Systems Staff cannot remove the public library copies. We must have client care remove each copy for us.
We would like the effects of serials control limited to the library using serials control.
(SIG: We request that this be noted as a bug. Per Sirsi’s request, we have asked TLC to open a Client Care incident.)
4) System Holds in iBistro Need Additional Check to Prevent Extraneous Transits
We are requesting that a change be made to the hold processing routines to
check for whether the hold is coming in from WF or iBistro. If it is
coming through iBistro, do an additional check: Is the item owned by
the pickup library? If NO, pass it through as a system hold. If
YES, change range from SYSTEM to GROUP to prevent many additional
items from going into transit and crippling an already overburdened,
underfunded statewide delivery system.
Right now, if Library A owns a copy of a title but that copy is checked out, Library B’s copy on the shelf will be targeted to fill the hold. While Library B’s copy is INTRANSIT to Library A, Library A’s copy comes back and goes to the shelf. The patron actually can wait longer for the item; and the statewide delivery service delivers and item that could have been supplied by the owning library.
We would be happy if this were done as a property so that customers who do not have a problem with the functionality as it currently works can keep it; and those of us who need to can implement this method to reduce extraneous transits.
(SIG: We support this concern and request.)
5) Placing Holds Multi-Part Items
If different libraries catalog multipart items in different ways (Sopranos Season 4 v. Sopranos Season 4, Disk 1, Sopranos Season 4, Disk 2, etc.), then place hold screen lists the results from every library in the consortium in check box format, in an array that is both confusing and intimidating. Patrons either cannot find the option offered by their library, or, frequently think they are being offered a variety of ways of reserving the item (the whole set or just one CD), and if they check a box that does not correspond to their library, cannot place a hold at all.
The hold screen needs to be limited to items held by the library being searched. This is the way it works for all other items, irrespective of how they are cataloged.
(SIG: We request at least the option to turn off the use of subfield z to drive hold options, and will post this to an Enhancements Forum.)
Demand Management:
*Please document follow-up from March discussion in Nashville.
*Better documentation is requested.
*Please provide the status of limiting hold by Item Type or a group of Item Types.
*Please provide the option to turn off system level holds for non-circ libraries.
Policy Files:
*Better management of policy files is still necessary; it’s too labor-intensive.
*Please review security model— consider making it function-based vs. wizard-based. We will work in a focus group if needed; Michael Koehn/BCCLS has volunteered.
Reports:
It’s better for consortia but Oracle throughput remains an issue.
Internal Messaging:
Please consider an internal messaging capability to alert system users about impending shutdowns etc. without opening up the security holes associated with broadcast messaging.