[live-blog IGeLU Conference 2013, Berlin - please forgive typos etc.]
Q: Read-only access to the Alma configuration screens availability?
A: First let me explain what this is: it refers to the process during implementation, ExLibris performs the configuration in the first instance but once the customer has received the Certification Training, ExLibris doesn't do this anymore. This at the moment is near the end of the implementation just before Alma goes live. We've received this as an important feedback, that people want more transparancy and understand better the configuration options during implementation. By the end of the year we will have a read-only option for the configuration. This will first be at the fulfilment level. This will be incorporated as part of the permissions based on roles.
Q: Data quality and how to re-use cataloging already done is important. What is happening with the plans for the Alma community zone where we expect we should be able to find most records instead of searching them via external sources?
A: It's part of our key goals to improve efficiencies, focus on enabling streamlined sharing. We've started this by modelling this, we're at the stage where we work with the policies and cataloguing advisory group and expect to get results towards the end of the year. We presented the suggested model now and you will recognise real efficiencies in processes. We are finalising the development of those recommendations.
Q: Plans to share EzProxy configurations in the community zone?
A: The community zone isn't planned for that, but it's a good question and we should think about that.
Q: When can we expect to see license information in Alma's uResolver? (obligation to display copyright information in e-resources)? Will we ba able to rename fields or add local terms to be added to the uResolver copyright information when finally built out?
A: The option to show the licensing info is planned for the 2nd quarter of 2014. We will allow to adjust the wording of those fields to be more user friendly. This is in our roadmap.
Q: Cloud safety - What if anything happens to a Data Center? How will Ex Libris restore services to customers whose data and applications are housed in the Cloud?
A: We're aware that out Cloud is a lot of responsibility. We've looked at all the details for hardware, using the best hosting that we can find. We have 6 internet providers providing to the site, multiple firewalls, applications designed specifically and testing in that way. We've upgraded our backup, we used to do it on tape but now we do it on disc offsite. The ability to restore from there to another location would be much quicker than in the past. We have multiple ways to resolve such issues. It's easier to restore from site, but we can do it differently. Restoring is not a simple process. In a catastrophic situation, it would be less than a year... But more like a week...
Q: When can we finally expect daily analytics for Alma?
A: We've just announced that this is near release. It's been rolled out in 10 institutions of the US as part of the testing and it should be available to all customers by mid-October. The short answer is that it's already there.
Q: WorldShare Management Services is OCLC's response to Alma. Although Alma is more mature, given WorldCat as the primary cataloguing datase of WMS do youreally think it makes sense to build a second (semi-)global Bib library within Alma?
A: We want to build efficiencies in processes, not to re-build WorldCat, which was designed a few decdes ago. We're looking into the future. We want to integrate any existing service that is useful to you. Such environments includes WorldCat and this can be included in Alma. Wheter you're an alone-institution or part of a consortium, integration is possible. Others who don't work with WC may find new efficiencies in Alma.
Q: OCLC has recently published info about the WC metadata API. What about ExLibris, planning to integrate in Alma (looks like a good replacement for Z39.50)?
A: We've started discussion with OCLC about this, it's on its way
Q: UStat is the first SaaS component from ExLibris. How long will it remain as a separate product for sfx users? Will it's functionalities be integrated in Alma?
A: Alma anlytics will have greater functionalities
Q: Does Salesforce offer a Claud Status page in order to indicate when the servesr hosting Salsefoce CRM are down?
A: We will post in our Customer portal page the status of our services, including Salesforce
Q: The Ex Libris Customer Center platform is not easy to search, after developping such a good product like Primo, can we expect the same for the Customer Centre?
A: Priority is on services to users but we will look to improve the search engine for the Customer Centre next year
Q:With OA issues, this changes how content is made available. Ins SFX, with effect in Primo, we work at Journal level but OA is at article level, how will ExLibris manage this?
A: Part of our next linking project is to provide this info to the link resolvers
Q: Are e-book loans sheduled in any ExL software?
A: This is more of a question for vendors and we'd be interested to see vendors' models
Q: How far did the implementation of RDA in combination with Aleph & Alma proceed?
A: Voyager team work closely with the Library of Congress team, Aleph didn't need to do any configuraiotn work and Alma cataloguing support will be finalised in the next few months. Next steps: all eyes on on bibFrame but they've not agreed to implement FRBR they're working on a new model also don't think MARC21 should be the standard, so it's too soon to say on how we'll move forward on this question.
Q: Primo was launched as part of the strategy to decouple the frontend from the backend.Many primo services are availabolo only to Alma users and the front end of Alma *is* Primo, could you expand on this strategic shift to a monolithic (or symbiotic) couple?
A: It's tactical/pragmatic rather than strategic. The dicoupling process between front and back end are still relevant, both Primo and Alma can enable 3rd party component. Next gen framework is still relatively young, we develop a lot of user case but we still don't have enough best practice etc. but it will come. Tightly connected interaction between A & P is based on interfaces
Q: Marketplace for metadata requires cooperation between all parties. What about collaboration with EBSCO? Other discovery tools seems to be able to agree with each other to share data. Why not Ex Libris?
A: Good news is that it becomes more apparent what's going on and that EBSCO doesn't enable the subscription based index for discovery services such as Primo. You have to buy EDS to access EBSCO content so you are told to buy another discovery system. Otherwise it would be through API. Indexing is the best way to do it but they offer their service through API. This is a problem especially for those of you who pay for this content. We find it hard to find a way around it. In terms of other deals, when it comes to conent and aggregators such as EBSCO, their content is not unique and we are making good progress to provide alternatives. We sign deals with publishers.
Showing posts with label analytics. Show all posts
Showing posts with label analytics. Show all posts
Tuesday, 10 September 2013
Sunday, 8 September 2013
Alma analytics
Asaf Kline, Alma Product Manager, Ex Libris
[live-blog IGeLU Conference 2013, Berlin - please forgive typos etc.]
Roadmap goes from descriptive analytics to predictive analytics (=how should we take action) to prescriptive analytics (=what will happen). We're still at the stage of descriptive. This should help to have a deeper understanding of what's going on in your library. Alma is optimised for anlytics e.g. cost per use etc. We are doing a lot of work behind the scenes to make this happen. The model is a star schema, in the middle there is a fact and then there are different strands. It's optimised for reporting. There is a shared platform and institutions can share their anlytics data. It is also role based, so any report or dashboard created is sensitive to an individual's role.
There is a functionality to schedule and distribute reports. Any user can subscribe to the reports that they want to receive. Analytics work with APIs because for any report created you get an xml representation of the report and it can be sent to the programme of your choice. The analytics provide a history and that's how it can be predictive, because based on previous years, we can see what may happen (e.g. funds burn down).
Usage and cost per use. We take the counter info from the vendor and provide you information
from subject area and from within Alma. We use Ustat for loading in a vendor usage via a spreadsheet or sushi. When we know what's in your inventory and how much you pay for it, then
we can provide cost per usage data. Usage is on a title level but when libraries buy packages, we bring up the title data to the package level and give data for the package. The analogy is like a TV - we pay for lots of channels and may only watch two. What's important is the cost per usage, not so much what we watch. (Question here: we often raise purchase orders at package level but get invoiced at title level so that could be a problem?...).
This has been a central activity in 2013, now being rolled out to Data Centers with a continuing effort to ensure scalability of infrastructure. There are additional subjects that we're working on:
- Usage (Alma generated)
- Requests and booking
- Vendors and vendor accounts (more analytic in nature)
- BIB (bib data) - unfortunately analytics and MARC don't work well together so we will have tools to search for and process info that we have in the catalogue so at the moment there is the option to choose 5 local fields to get data from
Usage data is Alma generated, captured via the Alma Resolver, it will answer questions such as:
- What services were provided?
- What queries ended without any services?
- What were the sources/ip ranges that accessed the system?
We want to provide a set of tools to gain insight into the structure and use of your collection, e.g. print or electronic inventory and usage, but we're missing overlap analysis so e.g. comparing titles from a package so it's combining a system job that we run together with analytics. We want to take our tools to collection level, e.g. shelfmark/classification ranges, and embedd it/make it actionable so that it becomes part of the purchasing workflow, based on facts and analysis. We also want to start generating KPIs (performance measure), to help evaluate success or sucess of a particular activity, e.g. how much time it takes to process purchase order or vendor supply, avg % of items not picked up by user, request processing time etc.
The data will also be made available to be viewed on mobile devices. We want to bring it up to network level, i.e. cross institution reporting, using benchmark analytics (comparing to others "like me") and network analysis (members of a consortia), so this is more about disclosing strength/weaknesses/overlap and how collaboration can be improved.
[live-blog IGeLU Conference 2013, Berlin - please forgive typos etc.]
Roadmap goes from descriptive analytics to predictive analytics (=how should we take action) to prescriptive analytics (=what will happen). We're still at the stage of descriptive. This should help to have a deeper understanding of what's going on in your library. Alma is optimised for anlytics e.g. cost per use etc. We are doing a lot of work behind the scenes to make this happen. The model is a star schema, in the middle there is a fact and then there are different strands. It's optimised for reporting. There is a shared platform and institutions can share their anlytics data. It is also role based, so any report or dashboard created is sensitive to an individual's role.
There is a functionality to schedule and distribute reports. Any user can subscribe to the reports that they want to receive. Analytics work with APIs because for any report created you get an xml representation of the report and it can be sent to the programme of your choice. The analytics provide a history and that's how it can be predictive, because based on previous years, we can see what may happen (e.g. funds burn down).
Usage and cost per use. We take the counter info from the vendor and provide you information
from subject area and from within Alma. We use Ustat for loading in a vendor usage via a spreadsheet or sushi. When we know what's in your inventory and how much you pay for it, then
we can provide cost per usage data. Usage is on a title level but when libraries buy packages, we bring up the title data to the package level and give data for the package. The analogy is like a TV - we pay for lots of channels and may only watch two. What's important is the cost per usage, not so much what we watch. (Question here: we often raise purchase orders at package level but get invoiced at title level so that could be a problem?...).
This has been a central activity in 2013, now being rolled out to Data Centers with a continuing effort to ensure scalability of infrastructure. There are additional subjects that we're working on:
- Usage (Alma generated)
- Requests and booking
- Vendors and vendor accounts (more analytic in nature)
- BIB (bib data) - unfortunately analytics and MARC don't work well together so we will have tools to search for and process info that we have in the catalogue so at the moment there is the option to choose 5 local fields to get data from
Usage data is Alma generated, captured via the Alma Resolver, it will answer questions such as:
- What services were provided?
- What queries ended without any services?
- What were the sources/ip ranges that accessed the system?
We want to provide a set of tools to gain insight into the structure and use of your collection, e.g. print or electronic inventory and usage, but we're missing overlap analysis so e.g. comparing titles from a package so it's combining a system job that we run together with analytics. We want to take our tools to collection level, e.g. shelfmark/classification ranges, and embedd it/make it actionable so that it becomes part of the purchasing workflow, based on facts and analysis. We also want to start generating KPIs (performance measure), to help evaluate success or sucess of a particular activity, e.g. how much time it takes to process purchase order or vendor supply, avg % of items not picked up by user, request processing time etc.
The data will also be made available to be viewed on mobile devices. We want to bring it up to network level, i.e. cross institution reporting, using benchmark analytics (comparing to others "like me") and network analysis (members of a consortia), so this is more about disclosing strength/weaknesses/overlap and how collaboration can be improved.
Subscribe to:
Posts (Atom)