| 2009 Survey Results | 2008 Survey Results | 2007 Survey Results | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It is difficult to answer this survey when the library is a member of a large, diverse consortium. A recent "needs assessment" survey shows widely disparate needs. Some institutions could migrate to and use an open source ILS like Koha, others need deeper functionality such as that proposed for OLE. But a limited few are more interested in a transformational product, like the conceptual ideas behind the ExLibris URM (but no current business model), as a replacement for a traditional ILS. Most open source ILS take a traditional approach--basically the same operations translated to a new language. What's needed, and perhaps OLE may do this (although I'm not optimistic) is a new approach to resource management.
Those considering adopting ALEPH should be aware of a few things: While highly configurable (and it truly does have great potential), the utilitarian configuration and maintenance of it requires a robust and savvy institutional IT staff. The demands that will be placed on them are easy to underestimate, as customization of this beast is woefully essential. It simply cannot be used in its out-of-the-box state. Astonishingly, given its improbable length, the provided documentation for this thing is inadequate. Anticipate alternating bouts of weeping and mocking despairing laughter. There are also significant issues with its archaic architecture and numerous hard-coded features that are impossible to work around. Its much-maligned reporting and statistics components, while easy to target for their inadequacy and staunchly counter-intuitive nature, have improved somewhat over the years. However, Ex Libris is so aware of the problems with the built in reporting functionality that they're eager to sell additional software to their clients, so they may more readily extract the necessary statistics from their ILS. Take note: this is a great way to monetize failure. It must also be noted that Ex Libris' revision process is staggeringly far from responsive to user needs. In the worst case scenarios, long-standing problems will finally be fixed in the current version only to be backed out of as soon as the newest version rolls out, starting a new years'-long ordeal of petitioning for change. This has happened and serves as a fine working definition for whatever the opposite of customer service is. That being said, these issues principally impact the staff-side of things, which can almost universally be worked around, no matter how inconvenient or inefficient it may be to do so (and sadly, you can expect routinely automated tasks to be rendered manual once you've adopted this ILS). The absolute worst component is the patron-side. The OPAC is a consummate dog (no disrespect intended to canines), guaranteed to frustrate and retard users. So don't embark down this road unless you also have plans for an alternative front end. This raises an interesting question: if the back-end is unwieldy, the front-end is unusable, and the customer support is vacuous, what value are you getting from your high-priced ILS?
With the current budget crisis, we have to make every dollar count. The service given by our current ILS company does not match the ever-increasing maintenance fees charged. We can no longer justify it.
In my opinion, our problems are related to inadequate staffing at the local state network office. Moving to open source would require a robust solution for consortia.
We are beginning the process (with our 15 consortial partners) of examining options among commercial vendors, open source, and hybrid products (like OLE).
Service from Ex Libris ranges from indifferent to non-existent.
Did not comment re whether customer support has improved in the past year because customer support has always been excellent.
We are already running Primo as our primary discovery tool. We limited our responses to the core ILS (Aleph) and did not account for Primo in our answers.
We are in process of implementing Primo as a search interface and happy with the functionalities and services, especially in combination with the Primo Central solution coming out end of the year
If we could afford it, we would be looking for a new search interface for the catalog.
We have recently implemented Primo. In the next year or so we intend to review our ILMS (and related products) with a view to confirming that what we have is the right fit for our needs. This may or may not lead to a change. The need to consider the implications of the new ILMS from ExLibris (URM) will also drive this review.
There is not much differentiation in the market place
Es una herramienta robusta y compleja, se carece del conocimiento completo en su estructura interna, sus manuales no son claros y el soporte técnico es deficiente.
I am no longer directly involved in implementation of service packs and new versions, and have therefore not given my opinion in this area. Primo is under consideration but the cost is very high.
I personally, and I think the library, would like to consider all ILS oprtions, including Open Source, but being part of a state system, it isn't up to us.
Obtaining Circulation statistics is difficult and cumbsome.
My vision is that it is tie to migrate from proprietary ILS to FOSS solutions. In general for building any digital library modules we can find several FOSS products, which can compete with commercial analogs.
We are planning to migrate with our ILS to new version 18.
If we were considering an ILS migration, we would definitely look at open source.
We will also be participating as a member of the [...] in the development of the Kuali OLE project.
We currently run Endeca as a search interface. If purchase Summon (or something like it), it's not yet clear what that might mean for Endeca.
We're very interested in a product that will combine our resources in a way that makes sense to our users intuitively. WorldCatLocal seems to be more focused on bells and whistles whereas Ebsco's product seems more focused on providing the same services but including the full content of non Ebsco materials as well. At this point we''re more likely to go with a product like EDS.
Some staffers at [...] (certainly me among them) would like to consider open source ILS, but administration has exhibited no interest whatsoever. To the best of my knowledge they have not looked beyond ALEPH at all, and will most likely not do so until long after most other libraries have implemented open source.
Many of the support issues that we have are complicated more by the consortial arrangement we have than by any willingness or competency on the part of the ILS provider.
Our current ILS is run by a consortium, so we would probably switch systems along with the consortium and not by ourselves.
Our library is part of a Consortium of libraries and the final decision on staying with Aleph or going to another product is not ours. But if our library could afford to purchase another product on our own we would leave Aleph. When you do get an answer it is usually worded as rudely as possible. They promised many features that they did not have. The system is lacking basic circulation functions that actually work or produce the correct information.
This is a consortium decision, not our individual library. The consortium already has a task force at work searching for a better system
We're in the process of re-assessing some of the configurartion decisions made during implementation, and planning for a version upgrade (18 to 20). We could and should be using many more of Aleph's features...
The [...] is a member of the [...], a 17 library consortium, sharing the same ILS. There is a central IT division that handles relations with Ex Libris. Therefore, we cannot assess the responsiveness and customer support of our ILS provider. We deal exclusively with the staff of [...] when we have problems.
In a month we will upgrade to Aleph v.20. We use Primo as our search interface and are happy with that.
Considered Primo but found it to expensive and required too much set-up. Need a product like Verde but disappointed by what we hear about it.
We have developed our own federated search tool based on Carrot2. I want to pull our Aleph data as a source. For the convenience of the customer and also because I feel the Aleph OPAC is not the most intuitive, at least for figuring out what to do once you have a list of search results.
We are very interested to watch the development of Ex Libris' URM or similar tools which may address new backroom workflows. We are committed to looking at modular, interoperable systems which run using standard interfaces and protocols. It is critical that we be able to integrate any external/commercial product with the suite of tools we are building locally - again standards and interoperability are key concerns. We very much dislike a "black-box" approach (although understand the commercial need for it sometimes...) - at the very least, there should be good APIs included with future systems.
Ex Libris must bring the Customer Care program available for European Customers to the US. It will have a great impact in the lives of the customers to be able to speak to someone and, most important, be heard with our problems and concerns. URM is almost a reality so we need to be constantly informed about the Uncertain future.
We are most disappointed with the behind-the -scenes configuration of Aleph. It is very complex. When set up, the user interfaces work fine even though they are not very user friendly.
We are currently using WorldCat Local Quick Start as a beta to test their interface.
|
|
|