Carmit Marcus Director of Product Management Ex Libris Group
Paul Bracke Assoc. Dean for Digital Programs and Information Access Purdue University
Janet Lute ILS Coordinator Princeton University Libraries
Bart Peeters Head, Operations LIBIS/K.U. Leuven
From the Partners’ Perspective
Alma Development Partner Panel
Today’s Presentation
• The Ex Libris perspective – Carmit • Reporting and integration with an LMS [for
Boston College] – Carmit • Data migration for partner release testing – Paul • User management – Bart • The impact of the Development Partners – Janet • Q&A - YOU
Collaborative Programs
• Development Partners (4 customers since 2009) • Australia Collaborative Partnership (8 customers
since 2010) • Early Adopter programs in Europe, North
America and ANZ (expect a total of 20+ customers)
Working with our partners
• Conceptual design phase • Testing of Partner Releases • Migration of data • Workflows • User interface design • Terminology • Cloud environment
Development Partner Releases (“PRs”)
- PR represents a working (but not full) system • End-to-end workflow orientation
- Migration of matching customer data and configuration
- 3 months of testing allows Partners to • Verify migrated data • Test functionality exposing staff to new system
while using real data to ensure real-life scenarios • Provide useful feedback and positively affect
product functionality well before general release
Based on a presentation provided by Bob Gerrity, Associate
University Librarian for Library Systems and Information
Technology, Boston College
Presented by
Carmit Marcus Director of Product Management
Ex Libris Group [email protected]
One year ago
Partner Release 1 September 2010 -Aleph data loaded -Not much functionality
Today
Partner Release 4 September 2011
Today
PR4, Sept. 2011: staff-specific tasks and customizable dashboard, with reports
Partner Release 4 September 2011 -Staff specific tasks -Customizable dashboard -Reports
Today
Collaboration on Reporting
• BC requirements for Alma • Better reporting tools within Alma
- With Aleph, we’ve had to create many reports outside of Aleph/ARC, to meet local needs
• Ability to extract all of our Alma data into data warehouse
- Local warehouse includes additional local data sources (e.g., student class enrollment information from student information system)
- Makes data mashups possible
Local reporting from aleph
Alma Reporting – Collaboration
• Ex Libris presented the concept of Analytics • Focus on Acquisition • Reviewed and analyzed examples created by Ex
Libris • Brainstormed about the type of analytics Boston
College wish to have
Example - Monographs and Serials Expenditures
Example - Predicted Funds’ Burn Down
Collaboration on Course Reserves
• BC requirements for Alma • support for CR digitization workflows
• currently workflows are managed manually, outside of Aleph
• discovery via Primo desirable, but bigger interest is in ability to create CR services that can be embedded elsewhere (eg, LMS, mobile interface.
Course Reserves Digitization Workflows
My Course Readings: Personalized Mobile Service
My Course Readings: Personalized Mobile Service
My Course Readings: Personalized Mobile Service
My Course Readings: Embedded link in LMS
My Course Readings: Embedded link in LMS
Alma – Course Reserve API
• Integrate the Alma supplied reading list citations, and their status, into the Course Management System UI
• Provide a link from the Course Management System to view
the services the library can offer for a given citation
• Services the library may supply include: • Physical copies available at various locations, under
different loan Terms of Use • Digital copies, either created for the course, or previously
existing in the library's inventory • Accessible electronic links, licensed by the library either for
general use, or for specific use of the course students.
Presented by
Paul Bracke Assoc. Dean for Digital Initiatives
and Information Access Purdue University
Data Migration
(A key component of the preparation for testing) Partners test Alma using their own data, including:
• Mapping of ILS data to the Alma structure • “Rules” that apply to data as migrated • 4 main categories
1. Inventory information 2. Patron information 3. Funds information 4. Circulation Desk and Fulfillment Unit
organizational relationships
An Example: Migrating Inventory Information
50,000 bib records for PR1 and full file for PR2 and beyond
• Converted Voyager locations to Alma locations • Voyager: 3 locations for an item:
• Holdings location (MFHD 852) • Permanent location (Item record) • Temporary location (item record)
• Alma: 2 locations for an item: • Permanent physical location (Alma MARC
holdings record); • Temporary location (item record)
One of our challenges
Material Type Mapping • Difficulties due to inconsistent use of material
types • Couldn’t use GMD or depend on codes from
the item record • We used a table of codes from the bib record
to help determine material type (ex: print, microform, online)
• Cataloger worked with Ex Libris staff to develop the conversion table
Migrating Funds Data
Funds Information • Voyager – hierarchical structure
• Ledgers linked to fiscal periods • Three types of funds: Summary funds;
Allocated funds; Reporting funds • Alma
• Two types of funds: Summary funds; Allocated funds
Longer-term Preparation for Full Implementation
• Looking ahead to the new environment: what will be possible?
• Reviewing existing processes • Standardization (e.g., Circulation policies) • Optimizing workflows and staff resources • Examining roles and responsibilities
• Database cleanup • Bib records • Authorities processing • Ledgers, orders, invoices
Most Important: Rethinking Our Approach
• A new model • Community Zone / Local Zone • Control vs. Collaboration • Value to users
Alma User Management Igelu Sep. 2011 Haifa
Sep. 2011 Alma User Management 32
What? • User Management
• user maintenance, sub-module in Alma to manage users (= individual or organization that interacts with Alma)
• 3 user record types • Public users • Staff users • Contact users
• Users can be • Internal • Internal with external authentication • External
Sep. 2011 Alma User Management 33
Sep. 2011 Alma User Management 34
Sep. 2011 Alma User Management 35
How organized? • User record:
• Core segment • Multiple repeatable record segments:
• Address • Phone • E-mail • Identifiers • Notes • Blocks …
Sep. 2011 Alma User Management 36
• User role: all staff and patron activity within Alma is role based
• Roles define: • What a user can do • In what scope (library - institution – consortium) • A user can have multiple roles in multiple scopes
• Role profile/template • Automatic role assignment
Sep. 2011 Alma User Management 37
How organized?
Getting data in (out) • Context – objectives – challenges:
• Other institutional/consortial information management systems (SIS, ERP, …)
• Other institutional/consortial financial management systems (Bursar, …)
• Maintaining data ownership and integrity • Just-in-time delivery of the right user information
Sep. 2011 Alma User Management 38
Getting data in • 3 ways:
• File import (xml) • Calls to Alma web services • Alma invoking other web services
• Integration profiles and adaptors • Similar to other data imports
• Predefined profiles • Scheduled or on-demand • Adding or updating …
Sep. 2011 Alma User Management 39
Getting data in • Every external system has integration profile
with two sections: • Import
• Optimized for large loads of new users
• Synchronize • Optimized for ongoing updates
Sep. 2011 Alma User Management 40
Introduction
Sep. 2011 Alma User Management 41
Alma Operators define external systems
Sep. 2011 Alma User Management 42
Sep. 2011 Alma User Management 43
Sep. 2011 Alma User Management 44
Impact of the Development Partners
• Staff searching • Vendor and vendor account structure • Labels, wording and screen layout • EOD import profiles • Refinements to metadata editor • Navigation and record linkages • User roles and permissions
Opening Screen
PR1 & PR2
PR3
• Had to drill down to find your work space
• Looked like what it was, a prototype
• Task orientated based on roles
• Persistent searching at top of screen
• Ability to add widgets to aid in work
PR1 & 2
PR3
Staff Search
MARC Editor
PR3
Pre testing, PR1 & 2
Screen Layout and Usage
• Focus today on screen layout and functionality • Staff at Princeton looked at all aspects of
usability • The same principles can be applied to other
screens such as Item Editor • Reduce number of clicks / scrolling • Reorder data elements • Critically analyze screen real estate
Why is this analysis important?
• Not all data is loaded • Manual record manipulation will always exist • A ‘small’ task that is hard to complete is costly
in terms of time and staff frustration • Think of the staff who do a particular task • Alma is focusing on improved workflows so the
work has to flow
PR3 example
• Following two screen shots are a PO line item created for Ex orbe religionum
• Line created manually from the Bib record • Vendor account selected • Price entered • Fund selected
What is wrong with this picture?
• Too much bibliographic & vendor account information visible
• Bibliographic data could be changed • Order of data is not optimal: funding is right at
the end, copy and location is at the top • Too much information by default, have
collapsible sections • Labels take up too much room
PR4/PR5 changes
• Inline links to Bibliographic & vendor records • Limit the ability to change bibliographical fields • Sections collapsed by default • Data element placement is more logical • Some details collapsed into one section • Fund editing greatly improved • See most of the record without scrolling
Carmit Marcus Director of Product Management Ex Libris Group [email protected]
Paul Bracke Assoc. Dean for Digital Programs and Information Access Purdue University [email protected]
Janet Lute ILS Coordinator Princeton University Libraries [email protected]
Bart Peeters Head, Operations LIBIS/K.U. Leuven [email protected]
Questions?
