2004 Consortia SIG annual meeting recommendations for Sirsi

Executive Summary Consortia SIG Conference

October 7-8, 2004

Des Plaines Public Library

Consortia clients feel that Sirsi does not fully understand what library consortia are and how operational issues unique to consortia impact our use of the Sirsi product line. We recommend:

o There needs to be a Client Care team devoted to consortia staffed by people who understand both how consortia operate and how the software works in a consortial setting.

o There needs to be an Implementation Team for new consortial customers trained to provide them with the information they need to set up the Unicorn system appropriately. Too many times new consortia are forced to go to other customers for advice on system configuration at the same time they are paying Sirsi for implementation services.

o As primary service providers to their members, consortia are the “face” of Sirsi to libraries and patrons. Sirsi must make a greater effort to:
 Take the functional requirements of consortia into account when new software releases and products are in the design phase. The software design must be more granular to accommodate the needs of the various types of consortia.
 Perform rigorous alpha testing of new releases and products that adequately reflect the types of transaction loads large consortia can place on the system.
 Perform rigorous beta testing of new releases and products in consortial settings with the recognition that several types of consortia may need to participate in testing to adequately ensure its suitability in different environments.
 Not remove or break features that worked in previous versions when a new version is released – for example the 2003.1.3 release that removed patron browse functionality when keyword searching was added, the loss of USB receipt printer functionality in 2004, and the fact that bibliographic and circ property changes in 2004 are modified in completely different ways with completely different messages.

o Sirsi’s strategic planning affects our strategic plans. The existing core product still has stability issues. If the core software isn’t functional, consortia customers will not be able to recommend it to other sites and could be forced by their members to look at other vendors.

o Sirsi should focus on more realistic software development timelines that result in the release of stable and usable releases. It is impossible for consortia to plan and train members if releases are coming out too quickly or are too unstable to install.

o Sirsi must develop a better method to document and distribute bug fixes and release information about known issues to customers. This is particularly essential for consortia: being forced to install a release in order to get a bug fix is not particularly simple when many libraries/sites are involved. Information about known issues is particularly crucial for consortia in determining whether or not to install a release.

o Sirsi’s core product must be revised to allow consortia to operate efficiently. Some issues that we would like to see Sirsi address specifically include:
 ISAM architecture is obsolete, and the BRS search engine has too many limitations in large settings. Consortia are forced to compensate for structural inefficiency by purchasing much larger, faster, and more expensive servers than would be required with a more modern data base design. Application software stability and capabilities are also constrained, and finding and training staff to do sophisticated data extraction and manipulation (compounded by the reliance on API rather than SQL tools with ISAM) is increasingly and problematically difficult.
 The existing system requires too many repetitive tasks on the part of consortial staff members. For example, the management of circ and demand management maps is clearly designed for a small or medium sized single site library.
 The basic reports are not suitable in a consortial setting. Reports can’t be run in a timely fashion and are difficult if not impossible to run for all members. Director’s Station does not address the daily needs of our members.

 Consortial customers:
• Need a management tool (e.g., a code generator) to develop the circ map
• Need a configuration module geared for consortia
• Need a toolkit for designing and configuring iBistro

o Consortial clients would like to see Sirsi address both internal and external communication issues, such as:
 Poor communication between software development and client care.
 Poor communication among client care teams
 The website must be kept up to date.
 Better feedback when Sirsi requests input from customers either via focus groups, surveys, or beta testing.
 Much better release documentation that includes specific installation steps and post installation steps. Customers shouldn’t have to wade through hundreds of pages of documentation to discover the user database needs to be rebuilt after a new release is installed.

o To fully develop the consortia market, Sirsi must develop a better pricing model for consortia.
 Pricing needs to be more competitive for large sites – e.g. iBistro content is significantly higher than Web2 sites going directly to Syndetic or other sources.
 Pricing needs to be scalable. It needs to allow for a few, some, many, or most members of a consortium wanting to purchase a particular product.

The Consortia SIG members greatly appreciate Sirsi’s openness to receiving our concerns on these issues. We, in turn, are very open to providing any feedback, insight, and cooperation that will facilitate getting these concerns addressed. We look forward to Sirsi’s responses and to continuing opportunities to help Sirsi address the needs of its consortial customers.