2006 Consortia SIG Annual Meeting - Sirsi Response

Unicorn Consortia SIG 2006

Recommendations for SirsiDynix

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. (Note from R. Shurman: that document has been supplied separately by Sirsi.)

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.

SirsiDynix: We propose the following for your review:

1. Sales contacts: Each consortium’s Sales Executive will contact you by late spring, 2007 to discuss this issue and determine local preferences and situations. We will then either come to an agreement that we can record in our various client systems that is consortium specific, or, if enough similarities exist among the group we will propose a blanket policy for your review. Issues of particular concern today include the Sales Executive not always having a current list of consortia members (making it more difficult to keep consortia management staff informed) and the delicate situation occurring when a member library requests an ILS quote from us and specifically requests that we not discuss this further.

2. Marketing contacts: e.g., literature, promotions, invitations to various events at conferences, etc. We will use our marketing database for this type of promotional mailing which is intended to be generic and appropriate for both customers and non-customers. In this case, we will not single out consortia management for the promotion but rather include all libraries in our database. Note that in many cases we send promotional information to non-SirsiDynix customers as well as to our own customers so we do not believe that there is a need to change this policy. *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

SirsiDynix: We will review this, but our follow up question and note is that we are not in a position to test newer versions of a client against older versions of a server. This means that any local process that would result in lengthy timeframes of client to server “version mismatch” should be avoided. Note that in GL3.1 we have provided options that allow you to upgrade the client by library or group of library in order to stagger impact on the network. The same consideration for overly lengthy version mismatches applies, but we would be interested in feedback on how many sites are taking advantage of this and if it might solve the underlying issue.

*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

SirsiDynix: We will update the documentation currently on the Client Care site that discusses how to upgrade a single workstation running WorkFlows 2004 so that it is accurate for more recent versions. We will make the updated information available on the Client Care site in Spring, 2007. We can review additional software updates for version GL3.3 or later.

*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

SirsiDynix: In GL3.1 we have made changes to the upgrade dialog to note several of these needs and to make it much more obvious as to how the upgrade must be completed by a final login to the system. Let’s identify a small group of “volunteers” on this one, have a webex in which we review the current messages and processes, and then determine what else can be done to minimize issues. As a further update, we have meetings with several customers at Super Conference to discuss this issue. We will summarize the results of those meetings as a starting point. We are also reviewing this in light of MS Vista’s even more stringent security; the default MS Vista parameters will require us to make changes to the WorkFlows Client for Java in order to avoid requiring administrative privileges to even run the client.

*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. SirsiDynix: The previous two points were passed along to the engineering group. I will follow- up with a response when we have adequately reviewed our options.

*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.

SirsiDynix: A staffing review is underway, as well as a review of overall service hours. I’ll have more details on this topic in the coming months.

*Please evaluate and review the quality of Critical Care phone response including the answering setup.

SirsiDynix: We are undertaking a review of these processes and staffing – with an eye toward increasing overall coverage hours.

*These requests include installations performed by the customer and by Sirsi (especially Oracle).

SirsiDynix: We are now in the process of reviewing and modifying our policies and procedures on this point. Our plan is to expand the support that we provide to customers, after hours, for updates and upgrades. This would include Oracle. I cannot provide an estimate of a timeline at this point.

*We can’t have Oracle upgrades done during online hours per current Sirsi practice, too much compromise of service to our constituents.

SirsiDynix: I agree that it isn’t practical to ask customers to bring down mission critical systems to do minor patches. We are working on staffing to offer this service during non-peak usage times.

*Clarification of responsibility for embedded Oracle upgrades is needed; the license says the customer (library/consortium) is not responsible.

SirsiDynix: This is clarified in the document, “SirsiDynix System Support Guidelines”, which is available on the customer website. The document is excerpted below:

Oracle Support: SirsiDynix libraries can obtain Oracle licenses for running Unicorn either through SirsiDynix or directly from Oracle. If a library has elected to purchase Oracle through SirsiDynix, it is an embedded license and is limited to use only with Unicorn. In this case, SirsiDynix Client Care will provide support for Oracle and will obtain, and schedule the installation of, Oracle upgrades and patches. Should a library experience a problem with Oracle or have a question that pertains to its use with Unicorn, that question or problem should be directed to the SirsiDynix Client Care Center. Please note that SirsiDynix is not contracted to act as an Oracle DBA; SirsiDynix simply supports the licensed use of the Oracle product within Unicorn.

*Client Care needs better knowledge of whether a site is full or embedded Oracle.

SirsiDynix: This is documented in our call management system and staff has been reminded to review this when working with customers.

*Client Care needs a better command and understanding of Oracle on a Linux platform.

SirsiDynix: We continue to train additional Client Care staff on Oracle and Linux.

*Installers should leave checklists of what they did.

SirsiDynix: This request was forwarded to our Product Delivery group. This group uses checklists to install software and the suggestion was made to leave a copy of that checklist in a directory on the customer’s system.

*Please disseminate Terry’s recent document delineating the different varieties of support to the SIG or provide the URL.

SirsiDynix: This document was reviewed and updated and posted back to the customer website. It can easily be found be searching the title: “SirsiDynix System Support Guidelines”.

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.

SirsiDynix: Each of these points was discussed within the Client Care management structure. Communication points were created and meetings were held with all Client Care teams to disseminate this information. Client Care analysts were given instruction, with examples, on how to create appropriate responses.

New module implementation:

*We need better set-up help without extra charges.

*Implementation managers need to be more cognizant of consortium and general implementation (vs. configuration) issues.

SirsiDynix: This feedback was presented to the implementation group. SirsiDynix has always included set up fees for new modules in the module pricing. We are reviewing this practice and looking at ways to standardize service fees.

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.

SirsiDynix: We are considering the first point above in our global review of the content of, and, how we write, publish and distribute documentation. We are working with the UUGI executive board in this effort.

We thank you for the positive feedback on the patch management tool. We continue to improve the use and functionality of this tool.

We request the promised follow-up and clarification of status.

SirsiDynix: We will be showing some new searching prototypes at SuperConference that we believe can be expanded to address FRBR intents (i.e., consolidated hitlist displays of multi- edition/format works to improve patron navigation).

Normative Data Project: Please provide the status of consortium level access.

SirsiDynix: This is still under review and has not yet been scheduled.

General Software Issues:

*Don’t break it when you fix it!

SirsiDynix: Clearly this is our goal as well. At SuperConference, Talin Bingham, our new since last SuperConference CTO, will be discussing a suite of automated test tools that we believe will improve our QA process. In the interest of practicality, we must acknowledge that there are thousands of workflow scenarios in Unicorn, and these are heavily affected by policies and properties. We are initially focused on creating test scripts for new functionality that is added and will be gradually adding regression tests, starting with most commonly executed tasks.

*Please provide a status report on automated testing, especially in a consortial environment.

SirsiDynix: Please plan to attend Talin Bingham’s sessions on automated testing at SuperConference.

*Please provide a status report on load simulation testing.

SirsiDynix: We perform load simulation testing at each major version release and compare major circulation, search, and dataloading transactions in order to compare the previous version’s performance to the new versions. Any significant negative difference in the new version is investigated and typically holds up release of version release. We started this process with Version GL3.0. Note that this testing involves running server transactions and does not fully emulate staff client to server transactions. The new automated testing tools also allow us to review client to server transactions. We have already begun using them for testing Horizon 8.x and plan to use them for Unicorn and other products in the future.

*Please do more usability testing with novices vs. experienced system users.

SirsiDynix: We have greatly benefited from extensive user testing in the Rooms/EPS environment, and in fact have formal usability reports for Rooms/EPS. In GL3.1, we expanded the beta processes to include significant additional webex reviews of software with beta customer, and we expect that this type of review will only grow. For GL3.2, we have actually conducted several reviews of this type during the development cycle and have made associated changes to the software. A new development cycle consisting of two week “sprints” has greatly expanded our ability to perform this type of testing.

*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. SirsiDynix: No, we have not shifted development resources from Unicorn to Horizon or vice versa at this time. In some cases, we do schedule development of a new component that is ultimately intended for multiple products, to start with one product or the other. For example, we anticipate having a single public access interface for all server types in the future, but it will be available first for Horizon and the Rooms/EPS development continues actively for Unicorn. We are developing new, web-based staff clients (intended initially for K12) against Unicorn first but we plan to use them with Horizon in the future as well.

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.

SirsiDynix: This will be reviewed in the GL3.2 development cycle. Increase of the total number may be scheduled after GL3.2, however.

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).

SirsiDynix: This is the case for GL3.2 and above (i.e., cases in which the user record is blocked or exceeded).

*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.

SirsiDynix: Further enhancements to standalone will be considered for GL3.3.

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.)

SirsiDynix: This will be addressed in Rooms/EPS in 2007, by version 2.3 of EPS. We plan to have this

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.)

SirsiDynix: We are going to provide additional documentation on “unavailable for display” situations. While we have made several changes to the software to minimize this occurrence, there are some situations that we do not believe we can resolve. On review of the documentation, we would appreciate your suggestions on any messaging we can provide that would be less confusing for end users.

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.)

SirsiDynix: We need to determine if this was actually logged.

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.)

SirsiDynix: We plan to support this capability in GL3.2.

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.)

SirsiDynix: This will be reviewed for GL3.3.

Demand Management:

*Please document follow-up from March discussion in Nashville.

SirsiDynix: A summary of the discussion in Nashville occurs below. Note that while there are some related items that are addressed in GL3.2, most of the outcome of the meeting will be discussed for GL3.3 as a significant update to hold prioritization to support unlimited “ordered fill” parameters has been added to GL3.2 and it was too risky to make additional major updates to Demand Management in the same release. Scenarios discussed in Nashville:

One of the topics of discussion involved better ways to process “Unfilled” holds. We discussed the following:

 In 2003.1.4 we added a configuration option that allows holds that are suggested for filling via the Pull OnShelf holds report to honor new holds of higher priority that have come in since the report was run.  We also added in GL3.0 parameters that allowed libraries that are closed to be excluded from filling holds while they are closed, thereby decreasing the likelihood that a hold would be “stuck” waiting for someone at that library to indicate that it could be filled.  We also discussed that in GL3.2, a new option would be available for libraries that prioritize by pickup library that will allow unlimited, ordered hold fill parameters. This will make it easier to arrange for holds to be filled by libraries better able to fill it (e.g., geographically close to the hold pickup library and/or better able to fill more holds due to larger collections, etc.  We discussed adding an “unfill” option that would make it easier for a library to elect not to use one of their items to fill a given hold. This would then force the system to review other items more quickly. This will be considered for GL3.3.  We discussed associating timeframes with holds that would define how long a given hold might be attempted to be filled from a given library or group’s collection before other libraries’ or groups’ collections would be considered. There was some interest in this but not as much as for the “unfill” option.

Another topic discussed was adding “place hold” limits by groups of item types as well as single item types.

 SirsiDynix asked several questions; most are in favor of this addition and wanted it to work similarly to item checkout limits. We discussed several more complex ways that the “limit table” could be handled but during the meeting we decided getting the basic capability along with ability to consider a group of item types (e.g., all “video” item types) was the most critical. This will be considered for GL3.3.

We discussed having an iBistro “local holds only” option in the hold map to cut down on the time it takes to set up reciprocity among libraries for certain types of materials when holds are placed in iBistro. While some of this can be set up in general today, it is very cumbersome in the hold map and it does not apply to iBistro only. Update: a small piece of this functionality is planned for GL3.2 with an option for holds that are placed in iBistro to revert from “system range” (if system is the default) to “group” or “library” range if the group or library has items that can fill the hold. This initial change is really more intended to prevent unnecessary routing of items to other libraries than meet the full goal of the request. We will consider updating the hold map with iBistro specific items in GL3.3.

*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.

SirsiDynix: Noted. The latter two options will be considered for GL3.3 (GL3.2 project was already in progress and additional demand management work could not be accommodated. There are significant new demand management features that support unlimited levels of hold prioritization via a new “ordered fill” policy for libraries that prioritize by pickup library included in GL3.2; given the size of that project it was not safe to add many additional demand management capabilities with the exception of the system/group hold from the OPAC as well as some new options that will be available for local request only or request exempt items in GL3.2.

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.

SirsiDynix: These are both tasks that may require significant development. I would suggest that after SuperConference we do further review with Michael and other sites on the web-based staff client (planned first for K12) to see if the model we are using for security there is more effective. We would appreciate your suggestions on management of the policy files and would suggest that this might be handled first by a meeting of the Consortia SIG to brainstorm with follow up meetings with SirsiDynix.

Reports:

It’s better for consortia but Oracle throughput remains an issue.

SirsiDynix: We continue to update reports to improve Oracle performance.

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.

SirsiDynix: This will be considered for a release after GL3.2.