Susan Stearns, Omri Gerson, John Larson - Ex Libris
Susan - URM from concept to reality
Omri - A peek under the hood
John - A user story
Omri - Ex Libris development methodology
Key Goals of URM
Unifying processing of all formats of materials and acquisition/ownership methods
Reduce TCO (total cost of ownership)
Location in the cloud, or SaaS, enables reduced cost of ownership/subscription/training on disparate systems
Ways to build infrastructure so it encourages new and innovative services
Interoperability between/among systems, not just in library land, but with information providers
Smooth migration from current systems to URM environment
Project is currently on schedule.
Susan's focus right now is on customer and vendor partnerships.
Fulfullment is difficult now - users have to know a lot about the back office - ILL, hold, call slip, photocopy, digitized, view online, etc - many different interfaces that match the back office systems.
Fulfillment in URL - present users with options and services they can understand - so have to do things differently, consider new ideas.
Some of those ideas:
Distinction between things that are one click away ("Immediate") - generally electronic and digital resources licensed by the institution or provided by a resource sharing network - and things that are more than one click away ("available", "wait in line", "we'll try our best") - physical resources currently available, physical and digital resources currently unavailable. "Available" doesn't mean "I own it"; could be from a resource sharing network - or request from last resort source or consider acquisition.
Focus is not on the format or acquisition method, but on the user's experience of trying to get the item.**Present content in ways users understand**
Shows sample end-user perspective from Primo, but points out that such a thing is not possible without a unified back office.
Two user questions - "How soon can I get it?" "For how long can I have it?"
They are working on Display Logic that libraries can customize to make sense for own location - similar to Display Logic in SFX, but on a bigger scale.
Shows another example from Google Scholar for articles - if have SFX button in Google Scholar, will get same results from Google Scholar that would get from Primo in terms of fulfillment; would also be the case from Oren's bX in Google Scholar example mentioned earlier today. They aren't developing URM and URD2 with the idea that users should be constrained to a single point of entry - believe that users should be able to get the same quality results and be routed into the library from multiple access points.
Immediate fulfillment isn't much of a challenge since link resolution works and is widespread. Fulfillment for items available with more than one click is more difficult. They are working on a decision system - a fulfillment plan - so that the system can make decisions based on item availability. It's not just a queue of requests since each request is essentially a workflow process. This Fulfillment Plan involves a better understanding of current request status, steps taken, and steps to be taken. Much easier to manage exception handling since "ordinary" requests are handled by machine, leaving staff free to deal with special cases. This system also supports analysis to tune library policies in order to gain efficiencies.
A course reserve user story to illustrate:
--Integration between different URM modules
--Distributed workflows to coordinate fulfillment
--Management of physical, electronic, and digital resources
--Automation and streamlining repetitive tasks
(Example is illustratory; steps aren't mandatory)
1) Faculty submits a reading list for course reserve (assume submitted via web form, although many other submission methods are possible)
2) Staff member approves existing items
3) Staff requests an item be digitized
4) Staff requests an item be purchased
5) Completed reading list is published
1) Uses link resolver in back office to create OpenURLs for items on list, locate items in local inventory, and offer links to use the available items.
2) Requesting an item to be digitized employs a back office version of the services menu - transfer an item from a particular location, request digitization - an interesting illustration of the fulfillment plan - an example of a request for a physical item that is in the end filled by a digital item. Have attempted to involve staff at the front end of the process - the human decision making happens at the beginning, for ex, then system routes and notifies based on those decisions and the fulfillment plan.
3) Digitization requests, in this scenario, attempt to involve staff only when necessary - when intellectual activities need to happen - questions like who will digitize, where will be deposited, etc. Can do single item work, but interface is set up for mass-item operations.
4) Item not in inventory results in choices to ILL or buy. Form for purchase request is filled in with item metadata for the staff member initiating this step. Initial steps of request send to a subject selector for approval, create purchase order, etc - all the stuff that happens when you order and receive an item can, for the most part, be handled automatically using the fulfillment plan.
--Integrated workflows across different formats: physical, electronic, digital
--System-managed workflows that cross staff roles and modules
--Automated processes that involve staff when decisions need to be made
--Service menu of federated request options across resource formats
Setting the stage - 3 Ts - Traditional, Transitional, Transformational - Omri's and John's prior points show work in first 2 Ts - can do those things well, but know less about Transformational work.
Paradigm shift respresented by URM requires a change in development processes; therefore, the development team's adoption of Agile development methodology. Agile will serve the 3 Ts of URM and other new concepts, including SaaS, Data Services, and others.
URM Conceptual design determines:
--Major flows and use cases
--Conceptual data model
--Major UI components
--Special architectural components and related diagrams
Conceptual design leaves room for required changes during the project lifecycle.
Have been working in 4 tracks:
--Cataloging (MMS, Inventory and KBs)
--Selection and acquisition
--Digital content - not separate because formats of items are considered separately (they're not), but because Digital Content has a lot of special considerations, some caused by its newness
What is Agile about?
--Promote a disciplined project management process that encourages frequent inspection and adaptation.
--Enables reacting to changes in requirements during the project lifecycle
Product backlog is prioritized by product owner; one piece of project moves from backlog into work group, gets a specific amount of time - 30 days at Ex Libris (called a "sprint") - with 24 hr turnaround on some parts (called a "scrum"); at the end of 30 days, have a potentially shippable product.Agile values:
--Individuals and interactions over processes and tools
--Working software over comprehensive documentation
--Customer collaboration over contract negotiation
--Responding to change over following a plan.
While there's value in the items on the right, we value the items on the left more.
These values inform the Drop concept (releasing URM to development partners in 5 drops):
--Continue cooperation between Ex Libris and the Development Partners
--Develop in drops that can demonstrate progress in all tracks
--Build drops around workflows that can demonstrate URM's benefits
Each drop will contain Functionality, Data conversion, and SaaS
Because of May sprint, is able to do a brief live demo to show some features - especially the organization of functions in the lobby screen. 18 months from general release and there's a live demo? Impressive...
What do gain with this approach?
--More impact from partners on product as a result of:
---Feedback > SW Updates > Review
---Start early and continue testing for a longer duration
---Ability to involve more people in the testing