In the ERM subgroup this week we started to look at the ERM Epics and Features in Jira.
We’d like to hear from the community:
Is there anything missing? What features would you expect to see that you can’t currently see in the features and Epics?
Is there anything you don’t understand? Are any of these features or epics unclear in terms of what they describe?
Is there anything that you were surprised to see there? Are there things in here you weren’t expecting to see in a Folio ERM application?
We would very much welcome discussion of these features - especially trying to answer these questions in this discussion thread. I will post some initial issues raised in our subgroup meeting, and responses, but please raise new questions and issues in this discussion topic
Is there an Epic/Feature for adding/removing titles to/from an existing package?
We discussed this on the call. The general idea is that you would ‘discover’ eresources that are described in external knowledgebases (such as GoKB and EPKB) and use those as your packages (if we regard a ‘package’ as some grouping of resources).
However, where there are ‘packages’ that are not defined in the KnowledgeBase you have access to, there is a question about how you might group resources and for what purpose. Some external knowledgebases may allow you to create your own packages which you could then use within Folio (specifically the eHoldings app currently allows you to create packages within your EPKB).
In terms of ERM we currently have two relevant features:
The first feature is about the ability to describe eresources that are not in the knowledgebase(s) you have access to
The second feature includes the ability to modify the list of eresources added to an agreement and the coverage included
The second feature, in theory, lets you specify exactly what is in an agreement, without having to rely on a ‘package’ to do this. However, the question was raised “how would you then connect a single purchase order line” to the group of resources in an agreement. It seems that this needs some more analysis for us to understand if this is the only requirement for grouping resources, or whether there are other things that would need doing to the eresources as a group. We will need to explore this further, but at least we need to add in the ability to have purchase order lines attached to a locally grouped set of content within an agreement
Will there be KBART-imports to add single resources (individual packages) to an agreement?
The feature “Create eresources” (https://issues.folio.org/browse/UXPROD-591) includes the requirement to
“Enable the creation of eresources directly in Folio either by data import or manual data entry”
This might be based on KBART, but it isn’t yet clear what the minimum set of information you would need to have to create an eresource and whether KBART holds sufficient information to meet this minimum requirement. We will be looking at this as we further analyse the feature
Is there some kind of document upload for other things than licenses (signed agreements, e-mails, …)? Will this be done by a general FOLIO-app?
We definitely want to support the ability to upload different documents. We are specifically thinking of this in relation to Licenses currently (we believe the Coral ERM model of hierarchicial license information with documents attached to different aspects of the license is worth looking at).
We will add to https://issues.folio.org/browse/UXPROD-580 to ensure addition and linking of different types of documents to licenses is explicitly included.
We haven’t yet given consideration to the need to attach documents to other things (e.g. Agreements) in the ERM module - this is probably worth more discussion.
The other example of the need for document upload was attaching a PDF of an Invoice to the Invoice record in Folio - which we need to check with Acquisitions
Which Epic/Feature covers the comparison of packages?
Comparison of packages of eresources will be done via the comparison of Agreements (which can contain packages or individual eresources or a combination of these). This will also open up the possibility of comparing other aspects of agreements alongside the content - e.g. price, terms
The comparison of agreements is covered by https://issues.folio.org/browse/UXPROD-575
Which Epic or Features covers the idea of being able to manage trials for eresources
https://issues.folio.org/browse/UXPROD-578 includes the need to support ‘Trial’ agreements. What this means in detail will be further fleshed out through user stories
What does “reference cataloguing” mean in https://issues.folio.org/browse/UXPROD-148
This Feature was written before the ERM subgroup started. It probably needs revising to reflect our current thinking on how this will work for ERM. However, I would understand the term “reference cataloguing” essentially referring to the idea that the external knowledgebase holds the relevant (“reference”) information describing the eresources.
Do we really (yet) need a functionality to “discover e-resources” in a knowledge-base? This seems to be very complicated (especially since we want to support different KBs). Maybe just entering the KB-ID might be enough to start with? https://issues.folio.org/browse/UXPROD-589
I think we need this for the reason Owen named in the ticket: “We need to avoid allowing the design and specification of the Codex to be too dominated by the two sources we happen to have right now. If we can add a at least one more source, then the use case for Codex Search will be more evident for SMEs and testers, and we can ensure both the UX and implementation won’t get any surprises down the line”
It may be that we keep this search quite simple in the first instance (although ‘only by KB ID’ would be extremely minimal). Noted that we should consider avoiding complex search options. There is also some discussion to have about whether this is something that happens within the ERM app/module, or whether existing Codex searching might be sufficient.
However, the key thing to bear in mind about this feature is that in terms of ERM that it needs to support the scenario:
“If the user identifies a resources which can be added to an agreement (within Folio or by searching an external system from within Folio), should be possible to add that resource to an existing agreement, or use the resource as the basis for creating a new agreement (without having to separately create the new agreement first)”
What are the priorities of the features? Which features are prioritised for v1?
We haven’t assigned priorities yet. We also haven’t assigned any of these features to releases of Folio yet. The way we’ve written the features at the moment (quite broad) might not be the best way to relate to prioritisation and releases - as they may be too large or broad to deliver in a single go.
Prioritisation is something we need to work at and we’ll be trying to do this over the next couple of weeks.
How do we manage agreements for hosting fees? Maybe there won’t be any specific resources to link. (so it seems to fall outside of the current Epics/features)
For the moment I’ve added this to https://issues.folio.org/browse/UXPROD-582 with the assumption that hosting and/or platform fees will form part of an agreement (the agreement may also have eresource content, or maybe a separate agreement that represents the hosting/platform fees).
This view may change as we better understand how these hosting/platform fees should work
In my experience, being able to locate a resource in the KB context ist fundamental, not only when you are about to set up a new resource, but to make sure of the status of stuff you stumble upon, like: “This journal is from publisher XY - why do we have (no) access?” or “We have canceled the p&o subscription two years ago - what about post cancellation access?” or “What are the licence terms for course packs for this E-book?” etc.
A search as implemeted in GOKb or KB+ is totally adequate - I hope it is what you call “quite simple”.
(“Welcome to FOLIO Discussions — thanks for contributing! Does your reply improve the conversation in some way?” Now THIS is intimidating! )