Statistical Report for Voyager

2009 Survey Results 2008 Survey Results 2007 Survey Results
Product: Voyager Response Distribution Statistics
CategoryResponses 0 1 2 3 4 5 6 7 8 9 ModeMeanMedian
ILS Satisfaction164 8 10 9 31 39 41 22 4 75.916
Company Satisfaction162 1 1 7 12 17 23 35 45 19 2 75.736
Support Satisfaction162 1 3 11 15 12 20 26 44 25 5 75.726
Support Improvement153 2 5 8 8 18 54 17 17 18 6 55.275
Company Loyalty160 11 5 5 11 14 22 20 42 17 13 75.516
Open Source Interest164 24 19 23 11 8 23 16 19 12 9 03.974

CategoryTotalYespercent
Considering new ILS164 3118.90%
Considering new Interface164 8853.66%
System Installed on time?164 14185.98%
Product: Voyager Response Distribution Statistics
CategoryResponses 0 1 2 3 4 5 6 7 8 9 ModeMeanMedian
ILS Satisfaction87 6 5 8 5 23 21 17 2 66.016
Company Satisfaction87 1 1 5 9 5 16 15 23 11 1 75.596
Support Satisfaction87 1 4 3 10 5 13 19 14 14 4 65.576
Support Improvement0 not applicable
Company Loyalty87 5 3 10 7 7 12 11 13 13 6 75.145
Open Source Interest86 10 7 10 6 4 14 7 10 4 14 54.665

CategoryTotalYespercent
Considering new ILS87 1921.84%
Considering new Interface87 4045.98%
System Installed on time?87 8395.40%
Product: Voyager Response Distribution Statistics
CategoryResponses 0 1 2 3 4 5 6 7 8 9 ModeMeanMedian
ILS Satisfaction83 1 3 12 3 17 19 22 5 1 75.516
Company Satisfaction110 1 5 9 14 13 17 24 21 5 1 64.935
Support Satisfaction108 4 5 9 13 14 14 18 19 10 2 74.885
Support Improvement0 not applicable
Company Loyalty105 16 2 11 13 9 25 9 8 6 6 54.155
Open Source Interest107 10 8 12 12 13 12 15 12 6 7 64.354

CategoryTotalYespercent
Considering new ILS111 2421.62%
Considering new Interface111 5347.75%
System Installed on time?111 10.90%

Comments

The only reason we are not considering a switch is lack of funds. Same reason we're not considering an additional search interface. We would consider open source if we had the staff to implement/support it, but we don't.

[...] runs our ILS (Voyager) with 14 separate instances of Voyager (Oracle) Databases. The 14 members are considering consolidating into one instance of the Voyager Database with all institutions in as 'branches'

Customer support from Ex Libris has improved dramatically in the past year. As part of a large, multi-campus university system, there is a statewide group undertaking a study of the potential for open source ILS solutions.

In my opinion open source ILSes have yet not proven to be scalable to the needs of my library in terms of number of records, amount of read/write activity, or web traffic. We will continue to monitor open source products as well as commercial products while we develop options in house, such as a native XML datastore. In the coming year we will test load data from our "traditional" ILS (Voyager), our ERMS (III), and EADs (eXist) into a native XML database to present seamless and unified access to our collections. Future plans call for us to migrate data from additional legacy systems.

With the amount of work that is required to implement security at Federal institutions per FISMA, choosing another system is prohibitive.

As a member of the [...] consortium, our library district does not currently manage the ILS itself, or have direct contact with ExLibris.

Dependent on consortium decisions to large extent. Budget restrictions locally and at consortium level limit what we can do now.

We are thinking about the place of the library in the wider enterprise. Why replicate functionality that already exists in the institution (finance, patron records, e-procurement). And why should patrons have to go into an OPAC to undertake functions that could be on their active desktops. We are really looking at the fundamentals and asking these questions. I don't know if in 5 years time we will have a traditional LMS.

We are in the process of migrating, primarily because it was too hard for existing staff to maintain the Voyager system, and we had trouble getting help when we needed it. We have selected TLC's L.S

Voyager 7.0.4 was totally untested when released. Major functionality was lost, much to the surprise of the vendors when reported. We had to cancel the upgrade at short notice after involving staff from 5 consortium libraries in intensive testing - a major waste of staff time. The second attempt at an upgrade was ultimately successful, but the release was still very "buggy". Response from the vendor was slow and they did not make an effort to fix bugs, many of which we have to live with i.e. we have had to turn off patron initiated short loan bookings on the web. Major step backwards.

We are monitoring the many developments with both commercial and open source developments. We are encouraged by the discussions/plans and hope to implement a much more open ILS in the future. The next 2-3 years will be most telling in the direction we decide to take for future implementation.

Currently use Primo as our search interface product

Because we are so small we rely heavily on our membership in the [...] for ILS maintenance. We will also rely heavily on the expertise of WRLC staff and staff of other member libraries in deciding on a new ILS.

We are a member of a consortium that share the Voyager system so any responses about the company and support are irrelevant. Our consortium IT staff handle all of the support issues.

Not likely to migrate to a new ILS until the new generation of back end systems, eg Ex Libris URM is released in 2012. Will probably implement a new search interface before then.

We are very satisfied with Worldcat Local and totally disatisfied with Voyager. As soon as OCLC can bring out its other ILS products we'll be migrating to them.

Being a small library with a flat budget we will not be implementing or even thinking about changing online services for a while.

We are using WorldCat Local for alternative search interface. We are part of the [...] , which is multi-library type. When we move to a new system we likely will do it as a consortium. To go with open source library system, we will need to restructure somewhat and have a centralized office with a number of dedicated programmers to support the system effectively for all library types.

Koha with Vufind is an extremely attractive prospect 3-5 years out.

Voyager still plans to continue its development. According to their roadmap, versions 8, 9, and 10 will be developed in 2010, 2012 and 2013. WebVoyage of V.7 already incorporated some web2.0 concepts. Currently, I do not feel that Open Source ILS is a feasible option for our community college system (LIBRIS with 12 community colleges in Connecticut). We do not have the level of funding nor technical expertise to develop and maintain. So commericial ILS with web2.0 incoporation might be realistic.

We are in the discussion of moving to OS platform. But, with Koha''s recent change, we are not sure which OS we should go with. We are actually at a crossroads again. We might wait to see what OLE project would bring about to the library community.

would like Aquabrower but can't afford it.

Evergreen needs some additional modules developed before we could migrate to it.

We are not actively looking for a new ILS at this time, but we are researching and trying to position ourselves to be ready in the next several years. We would make the move as part of a consortium decision. This year we are looking at workflows, primarily in technical services, to see if we can jettison, outsource or retool things to be more efficient

We are part of a network of schools and have no local control over our choice of ILS. I personally would consider an open source solution, but I find it highly unlikely that our parent company would go this route.

The new version of Voyager (7) was problematic - large number of bugs and not load tested sufficiently. Response from ExLibris was slow in acknowledging this, but once they accepted there was a problem, they did work hard to fix it.

We currently use Primo as search front end for ILS.

Lack of money prohibits any innovation or change at all. Library staff are very interested in acquiring a new search interface and other functionality, but without funding it is a moot point.

We are very interested in moving to completely open source solutions for our library systems. Our digital library and web services are already on open source platforms. As soon as a viable ILS product is ready for implementation we will move

Our interest in open source ILS or other software solutions is significantly restrained by attitudes and policies of our information systems department.

The use of our catalogue has been declining, in part due to its poor interface and also due to changing expectations / use patterns by our clients. We are not very likely to migrate to a new ILS as I expect this will be the last ILS we have for our organisation. We are likely to abandon our current ILS' user interface for something that actually works, while keeping the back-end acq and cataloguing modules.

ExLibris has been reaching out more to find out where there are weakness areas in their support. This is relatively new but has been very well received in our library

Plans are under development to study the ILS market including open source and make recommendations for a new ILS based on the results of the study.

We would like our current vendor to create an interface that works with XML and MARC without having to purchase additional applications for working with XML metadata.

We purchase through a consortium. The consortium also employs a full-time coordinator/liaison who helps all the sites troubleshoot technical issues and walks us through upgrades. So my assessment of our ILS's customer support is somewhat irrelevent, as I call my consortium coordinator instead of the vendor when I experience issues.

Customer/tech support is handled on a different campus, so those responses are based on conversations with others.

Our library does not have any plans for a major ILS change for at least two years, or until some viable options are in place. We are waiting to see how Ex Libris' URM plays out and we are waiting on some developments in the open source market that provide real working options for large academic libraries. Our expectation is a continuation of building our own "Frankenstein" out of the parts we need -- whether supplied by a vendor, through open source, or something we build on our own.

We purchased WorldCat Local because a discount deal was offered to a state wide group of academic libraries and that was the only option we could afford otherwise we may look into Primo or VuFind

We will be considering anew system when Ex Libris merge Voyager and Aleph

[...] is part of a 12 community college system. Most likely all 12 will stay with our current ILS or migrate together. We've had and will continue to have discussions on open source ILS.

We are probably a year away from deciding on a new ILS. Discovery software could come sooner if the price is right and configuration/implementation are manageable.

The transition of Voyager from Endeavor to ExLibris has been rocky especially as it relates to support of legacy software products. We have had difficulties with ExLibris staff not changing all the files related to an upgrade and this has caused much work for the library staff in tracking down the cause of post-upgrade problems.

We are in a dire situation here. Our hardware platform is failing more often. We attempted to get into the Beta program for the next release but were denied. Now it seems that the next release will not be available until Spring 2010. So you tell me? Is the risk of having a total systems failure worth waiting for the new release?

Unhappy with our OPAC but very unimpressed with a consortial Aquabrowser installation we've been part of as well...making us think seriously about renewing our efforts to bring up a VuFind-based OPAC.

We have an ongoing investigation into open source systems, but do not feel that any of them are currently robust or complete enough for us. We will continue to follow them. We are not currently looking at any other vendor systems. Serials Solutions Summon. We have also looked at Primo, Endeca, Aquabrowser, and a few others and have dismissed them from consideration for various reasons

this is a remote hosted system and we are in the first year of implementation. The problem we have in collapsing holdings statements is huge, and we are looking to figure out how best to provide users a clear and accurate holding statement.

we do not have the programming staff to adopt an open source product. Also, please note that our library's name is Helm-Cravens, not Helms Cravens.

We have no money, we have no staff, we have a server that is ready to die and can't upgrade unless we get a new server, and we can't afford a new server. We can't consider any new technology, such as a search interface. We haven't even enabled all the current capabilities of our ILS, due to lack of funding and staff. We have missed several upgrades and patches since our server can't accommodate them. Open source? Might be interesting, IF we had any staff who knew how to program. Unfortunately, we don't even have the library staff with the tech skills for day-to-day needs and depend on institution staff, who don't understand or care about library-specific needs for technology. Our administration does not understand library technology needs. Our user computer stations are now 7 years old. This is not because of the recent financial meltdown, but has been exacerbated by it. It's very frustrating. The tyranny of the upgrade. Our administration does not understand why our costs for networking are always increasing, and frankly, neither do I. This little comment box is not big enough to include the extent of my frustration and outrage. Also, why do I need a staff or a system librarian specifically for the ILS, this college's administration does not understand, seeing it as any other software that any network administrator can maintain. Well, why not? Is the ILS so "special" ? There is no option for a small and underfunded college library to get quality software product, because that's not where the money is- there is no profit is providing that kind of system, so we have not choices, all of the ILS are very robust, complex, expensive, and demanding of staff time, and we can barely keep up. It's ridiculous. There is no middle ground, or I haven't seen any, unless you have a sharp programmer or computer-language-savvy librarian. God help me if we ever need to migrate to a new ILS. We have actually been planning for what to do if we need to fall back on a card check out system- if the ILS fails, if the server fails, what will we do? We have no backup, no failsafe, and faculty, staff, and the administration do NOT understand and would not think that a card checkout system was so bad. Some think that's what we do now already. Back to the stone age. Sorry, I could go on forever. It's just really bad for small libraries with clueless administrators and shrinking funding. Shrinking to disappearing funding.

If we migrated, it would be to consolidate with other military medical libraries in the national capitol area.

We are looking for a public interface with increased functionality, a discovery tool that can include many of our licensed commercial databases, and an ILS that includes an integrated ERM. We are running a beta implementation of VuFind for our OPAC, and we are participating in an EBSCO EDS trail.

It's all about working at the network level. It's not so much about a single vendor solution, but rather taking advantage of the best of the best applications. The user needs a discovery/delivery matrix that removes barriers to access. Libraries need systems that minimize duplication of effort both within and among libraries.

While we are not actively searching for a new ILS at the moment, no ILS decision is permanent. We are considering beginning a migration search in 3-5 years.

Use open source for other systems such as Drupal for content management for some digital collections and soon for the web site.

The reason that [...] is considering open source is purely a financial reason. We are considering Encore because it enhances the search capabilities for our users. It also makes more use of information on MARC records.

We still do not have enough staff to implement and manage a new system, and we are dreading the next Voyager upgrade when we have to move off the old OPAC interface to one that is xml based. We only have a staff of 8 librarians, which includes the director, to service 6000+ students and faculty in a 40+ yr old bldg that is full to capacity. We see no new sales of Voyager and won't be surprised when Ex Libris eventually forces us to migrate to Aleph, for a substantial fee of course.

I think the service has improved as the prior company had poorly trained techs with bad coustomer service skills. When I call up it is because I need help and am too busy to sort through all the materials and then comprehend it. There are some major flaws in the catalog duplicate detector which I had to figure out myself as the tech people didn't really understand libraries. The ISBN number only checks a few digits and since the 13 digit system came in, I am getting many hits on different titles. This is really bad. When I called up tech support, they had no clue. I finally figured it out and they claimes that -OH yeah there is a bug-. I think the design team should include librarians with up to date skills and not some tech person writing codes.

It's no surprise, but cost is a major consideration for us. The cost to purchase a new system or to upgrade to the "next generation" of the current system. The same is true when considering "discovery" platforms such as Primo, etc. We have to be able to justify the outlay of some serious money to university administration. The survey is a great service. Keep up the good work!

An open source ILS would be of interest but of more interest would be a hybrid system where we could acquire the best components from several sources, open and closed source.

ILS