Recommendations and Executive Summary Consortia SIG Conference
September 29-30, 2005
Des Plaines Public Library
One of the ideas that came up time and time again was to have focus groups on a number of these issues with definite follow-up from SirsiDynix. Here are some areas for discussion and recommended suggestions for action by SirsiDynix.
Customer Service and communication
General Customer Care Responses and Actions
Is there a strategy or mindset on meeting support needs of consortia that you can share with us?
Better Communication between the teams and the company as a whole!
Quality Responses should be more important than response time. A wrong answer answered quickly doesn’t help anyone. We need answers for our customers and when we look bad, you look bad.
Consortia staff has already vetted our customers. When we call a sense of urgency should be understood from the get-go. Please be sure that Customer Care reads our logs.
Green Team
• Can we get locked up with the Green team for a day or have a focus group?
• Team is still not adequate– not enough knowledge across the team
• It still depends on who you get (this is actually true on all the teams.)
• Escalation is “the kiss of death” –once a problem is escalated, it seems to lose its priority status and isn’t answered for a long time unless someone intervenes unless you get your CAM involved.
• Deeper Training and Cross Training for the green support team and the other teams, including implementation teams as well. They need to speak to and learn from each other. Unix support is an example where more cross training is needed. One person per team isn’t enough.
• Why isn’t there really one team for consortia? Could we have a back-up consortia team, with proper communication between the two teams?
Sure Sailing vs. Client Care Account Manager
• Can we have an understanding of what is available for all customers? Everyone would like to be able to receive quality service without calling Mike Casale or a special contact to get it or paying for “Sure Sailing” or having a CAM unless it is available to everyone.
• Product problems or bugs should not be solved by Sure Sailing. The solutions should be readily available for everyone.
• Scripts and other solutions that are developed by Sure Sailing could be sold to other sites as well. “Here are custom API scripts for sale for $x amount.”
• Customer Support vs. Customized Support? The issues as stated above is that it seems that with Sure Start/Sure Sailing, you get quality support and responses but they aren’t shared with other customers or even the customer care or implementation teams. Problems should be solved system-wide and not customer by customer and quality results such as an API script, etc. should be shared so Customer Care and Implementation can share them with other customers. What happens to Sure Sailing results? They should be shared with other teams/departments and customers.
New Customer Implementation
The group thought that data migration was going very well and many felt that policy file configuration training was improved.
The concerns are as follows:
SirsiDynix Staff need to be “Consortia Ready” when they are bring up a consortia. It helps no one to always refer to “single site” experience and this happens a lot in training.
“Sure Start” should be standard with any migration. It might reduce the pressure on the customer care and implementation teams and it definitely would reduce the frustration level of the customer.
In terms of training new and old customers, the focus should be on the complexities of the product and not just the basics. We will talk about Demand Management later, but it is a good example. Letting a customer know something that has gone wrong at other sites and how it can be avoided goes along way to building confidence and trust. Just focusing on the basic issues and not discussing the hard stuff is very frustrating.
Hardware/Network Services
SirsiDynix sells the hardware but often doesn’t know how it fits in when there is a problem.
A better understanding of various hardware and known and suspected issues is important
Better communication between implementation and customer care teams in terms of known issues with hardware or just basic quirks, problems and workarounds. This will save a lot of time and frustration.
Monitor Size and resolution requirements need to be clearly defined and included in specifications, especially for the Java Client.
Can you explain the OS Support Process? What will you do and when do we need to call another vendor?
Are there guidelines about support/service with 3rd party vendors. It is frustrating when we call you and say there is an Oracle problem for example and then SirsiDynix simply calls Oracle. Guidelines about 3rd parties and support for hardware that we purchase from you would be very helpful.
It would also be very helpful to have guidelines about what type of networking services you still support. What steps should a customer take if there are bandwidth or networking issues. There seems to be a lot of confusion on this since you gave up a lot of your network service support.
Documentation:
A show of hands demonstrated that at least half the attendees write their own documentation.
SirsiDynix’s documentation is too overwhelming. Here are some suggestions.
Documentation should be “task oriented” and not a “wall of words”. It is too overwhelming and never really gets you the information you need.
A common glossary of terms that is used from client to client and module to module and upgrade to upgrade would be helpful.
Greater explanation of the IMPACT of doing something and not just a description of how to do it.
Often there are too many choices in the documentation in how to do something without knowing the impact or end result.
The new System Admin Notes are a good start. Full System Admin Documentation would be nice. We also think that less complex staff documentation might be better. What you provide now is too much for the basic staff person and not enough in terms of the impact and true details of the choices you provide in the documentation for system administrators.
Two other items came up during our panel discussions that we would also like to mention.
FRBR
A discussion of the potential of the standard for functional requirements for bibliographic records resulted in an understanding that Sirsi was looking at ways to implement these capabilities and the creation of an advisory team to work with Sirsi on this area that consortia feel is especially important. The Consortia Chairperson gave Berit Nelson a list of several interested individuals.
Normative Data Project
Sirsi agreed to provide an update on our concerns about whether or not Sirsi plans to provide Consortia level information within this project. As Sirsi customers we object to the fact that Sirsi broke apart our consortia data and loaded only site specific data into the NDP. We want aggregate data on the consortia level to be included in any load of consortia data. The current NDP uses our data but does not meet our needs.
The Sirsi Consortia Special Interest Group appreciates SirsiDynix’s interest in our concerns. We look forward to your response and working together in the future to meet the needs of your consortia customers.
Respectfully Submitted on behalf of the attendees of the 2005 Consortia Conference,
Carol Dawe
Library Integrated Network Consortium
Sirsi Consortia SIG Chairperson 2005/2006
Software:
General Software Issues
Develop a viable test process to test all types of data and for testing high volume usage in large sites.
A more modern Database would dispense with the many tools we have to use. (See Oracle below)
Have focus groups to see what the real software issues are for Consortium (and other sites as well.)
• These groups could be done via the web or in person but we think you need to hear from your customers directly and then you need to share the results of these groups with us.
o What is the plan to include consortia input into Software development? We need to see where the product is going from a consortia point of view so that we can plan and budget.
Revamp the Enhancement Forums and Discussion Lists and provide us with a timetable. Provide a software plan for implementing patches/upgrades for your customers with easy documentation that is easy to find. Here are some ideas:
• Develop a reliable “Patch Delivery System” for patch management. A timetable would be helpful. This would solve so many problems.
• Educate Client Care and Implementation Teams on patches
• Let us know the status and problems with patches as soon as there is a problem
• Give more details on KNOWN issues and SUSPECTED issues.
• COMMUNICATE –TELL US WHAT PROBLEMS HAVE ARISEN (and not just the known issues) so we don’t have to hear them word of mouth during an upgrade.
Specific Software Issues:
Edit holds in the hold queue. Ability to edit holds and place in queue.
Ability to “unfill” an item on the pick list using the functionality that Dynix has now–you “pass on the item” and it is out of the queue for that request. An email is sent to the site if the hold can’t be filled.
An easy way to communicate to all active users if the system is going to go down using something similar to “Instant Messaging” (which has security issues) but simplified.
Setting an item to missing or damage shouldn’t be related to circulation but rather it should be a status of sorts.
We shouldn’t need custom scripts to work around what JWF can’t do. Especially not when upgrades break scripts. Fix the meat and potatoes first.
• For example, sorting by zip code is basic bread and butter.
Don’t highlight first item in hit list. Too confusing.
Wizard Name and Button Consistency
• For example: Modify vs. Save in the new Java Client. Modify is very confusing. Save is much clearer.
Controlled Date Data Entry Screens and Data Validation
• Proper format or only certain formats would be allowed to ensure a cleaner database. Subfield Z as the volume designator in the call number is an example. A Subfield zz wouldn’t be allowed since it isn’t valid?
• Another example is Dewey Validation–currently errors throw off sorting by call number.
• Validation is also needed for fields used in notice generation (phone, e-mail or printed).
We need the ability to lock things down or provide some features to some users and not others without having to create various user access identities.
Separating Staff and User ID’s would be very helpful.
Oracle
• A timeframe for moving to Oracle is needed
• Often Oracle isn’t addressed during implementation and it presents problems when we are unaware that a whole set of patches are needed.
Demand Management:
Do a basic program on Demand Management at the SuperConference
Train SirsiDynix trainers, Client Care Staff, and Implementation Teams how Demand Management works in a consortium environment.
SirsiDynix needs an internal Demand Management expert
Hold focus groups to see what our needs are in terms of Demand Management. Do a SWOT.
Being able to “unfill” a hold. We will get you samples of this.
Create a fourth level of holds–hold zones and not just library, group and system.
Assign hold priorities.
Say no to a hold for certain time period.
Policy Files:
Be able to return to last line edited instead of returning to top of the screen.
Should be simple be able to insert a line without having to move it or reorder it!
Move multiple lines at once
Pre-populated template
Be able to use more than one item type etc. in each line of hold or circ map.
All/None Consistency in searching/policy files. For example:
• More consistency between the hold map and the circ map. Circ map shows all pertinent info, hold map should as well.
We would like to deal with policy at system level instead of branch by branch.
We would like the ability to have maximum checkouts spread across various item types
Such as various AV materials. Right now, if you have a DVD and NEWDVD, it is very difficult to have a clear number of maximum check outs. They have to be separate.
Reports:
Conduct Focus Groups about reports for consortia customers to improve them. We are all reinventing the wheel and wasting a lot of time and money in terms of staff.
A SuperConference presentation on “best practices for report-writing.”
We need to be able to track between libraries and not just library by library.
Better control of the output and we aren’t talking about Director’s Station but rather solid administrative reports.
Sorting by library
Better General Configuration
Library Selection piece could be based on user login. (A site did an API script but this should be standard.)
Other data validation could also be based on user login.
Easier way to restrict reports
More templates by library (but not only station library!)
The more fields we can use and less limits, saves us time.
We want simplicity, clarity and accuracy–fail safe idiot proofing as well.
We shouldn’t have to customize and write scripts for basic reports.
What about a report generator/writer and not just API?
An example of a much-needed report is a combined Circ/Renew Report.
Need a “Kill” button so that a user can kill a report easily. A “Kill ALL” button is also needed to kill all reports running at once.
The Consortia SIG members greatly appreciate SirsiDynix’s openness to receiving our concerns on these issues. We are happy to assist in anyway possible in order to get these concerns addressed. We look forward to SirsiDynix’s responses and to continuing opportunities to help SirsiDynix meet the needs of its consortial customers.