Update of the Open Access Reporting Checklist

The recently published checklist has been updated with the data required for version 2 of the RCUK APC spreadsheet as applicable to HEI APC expenditure reporting in January 2016. The changes were identified in an email from Stuart Lawson to the UKCORR discussion group dated 21st May 2015 and reported by Neil Jacobs on the Jisc Scholarly Communications blog .

Open Access Reporting Checklist for Institutions V2

Advertisement

Review of APC Intermediary Services

At the beginning of this pathfinder project I was tasked with examining intermediaries for APC payments, specifically in regards to reducing the administrative burden placed on HEI’s by Open Access, but it quickly became clear there was a problem – the rapidly changing Open Access environment we all deal with everyday had already moved past APC intermediaries.

Off the back of the JISC/OAK Pilot I spoke to CCC, EBSCO, Swets and Turpin Distribution. At first there seemed to be some interest in establishing intermediaries. But after initial positive responses, and some development work, the responses cooled down.

Turpin Distribution had presented at UKSG 2014 and mentioned the possibility of an interface for institutions in 2015. Now this has been delayed until a review in early 2016. EBSCO had plans in place but development has since been shelved. CCC still has potential given the services they supply for publishers, but it seems that any Institutional interface, if it comes at all, will still be a while away.

Instead of focusing on APC Intermediaries to enable administrative savings, these will instead have to come from Good Practice and further “bedding in” of Open Access processes and workflows into the operational life of institutions.

At the same time as the interest in Intermediaries was dwindling, the community had turned towards offsetting deals. When I started working on the project there was already information on offsetting in theory, and IOP had launched their offsetting pilot. We are now well and truly stuck into offsetting in practice, with several other publishers now offering offset deals following the work JISC has done establishing these deals and providing guidance.

The focus on savings has thus shifted. Any savings that we as a community might make now come from lowering, or controlling, the total cost of publication, rather than directly from removing administrative burden as was thought a little over a year ago at the commencement of the project.

My next blog post will examine these offsetting deals, the pros and cons of the different models that have been adopted, and how these deals are being embedded in practice, looking at the main pain points of implementation as well as things we would potentially change.

Finlay Jones
University of Exeter

Open Access Reporting Checklist and Sample APC Payment Workflows for Institutions

This checklist is intended to assist institutions in identifying data required for OA reporting to Jisc for RCUK (APC spreadsheet) and HEFCE for REF OA. We are aware of other work in this area but developed the guide with other work for our Jisc Good Practice Pathfinder project and we believe it may be useful for other institutions. It has confirmed there is very little overlap in data requirements for RCUK and HEFCE OA reporting.

Open Access Reporting Checklist for Institutions

Mapping workflows at our four collaborating institutions identified a generic series of ‘steps’ in each payment scenario used by our institutions. This led to the development of sample workflows for each payment method which we hope will prove a useful aid for institutions developing new, or adapting old, workflows. Institutions may need to adapt the sample workflows to suit their own requirements, systems and processes.

Sample payment workflows

We welcome feedback and comments on the checklist and workflows.

Report on the Jisc Monitor Review Workshop 26th March 2015

Review the Monitor Local and UK Aggregation Prototypes
Summary
The Monitor developers discussed the aims of their work, what Monitor is designed to do, the global and local models, and limitations of the current design. Prototypes of the data model, workflow, data fields and screen presentations were shown and feedback requested; was the right data included and what might be missing? The developers were keen to receive ideas for inclusion, questioned for clarity and understanding and accepted many of the numerous suggestions.
The prototypes are designed to fill current gaps in the OA landscape, additional work will be necessary to convert to a service. Alternative services or solutions may fill the gaps and in that case Monitor will cease further development and become redundant. If developed, a future system may be a local web or hosted service (the developers felt the latter was most likely) with an API to interface with other systems for import and export of data.
Details of their work published on Jisc Monitor blog See their outputs for details of the system specification and wireframes (screen presentations).
Monitor Local
Four work areas: publication, costs, compliance and tasks (monitoring progress, driving work). This workshop reviewed the costs requirements but other areas were discussed briefly.
Compliance checking is designed to be flexible as change is expected and it is possible to use the compliance element standalone (w/o other three elements) and interface to other systems.
The tasks display user interface assists in managing daily work by indicating ‘What needs doing?’ An indicator displays how complete individual tasks are and a task drop down takes users to different screens.
Monitoring of pre-pay accounts is not possible using Monitor. The Monitor Local data model maps to RIOXX elements.
Monitor Global
UK Aggregation – data could be fed from Monitor local or from proprietary apps or spreadsheets.
Uses:
 Leverage UK negotiation
 Reduce institutional reporting requirements
 Outing bad practice
OA compliance automation was demonstrated using a spreadsheet download (data included PMCID, PMID and DOI and title) to interrogate services e.g. EPMC, DOAJ, CORE, Sherpa and text mining of publishers websites. Potential reports from Global might include expenditure by publisher, expenditure in OA/Hybrid journals and by institution. Linking and comparison with KB+ to provide comparison of subscription spend and APC payments is recognised but some way in the future.
Monitor are demonstrating at two UKSG workshops (31/03/2015 and 01/04/2015) and welcome feedback in the next six – seven weeks.

Using Functional Cost Analysis to Evaluate the APC Payments Process

We are really pleased to release a draft for comment of our report on analysis of the administrative costs of processing APC payments in the four universities of the GW4 alliance: Bath, Bristol, Cardiff and Exeter.

Functional Cost Analysis (FCA) methodology was used to investigate labour costs per APC payment and identify resource intensive functions with a view to later improvement.

The document is available here.GW4 FCA Report.

In a nutshell, after mapping the workflows at each institution and developing a functional family tree, the time and effort were recorded for each function and sub-function, giving us an idea of what was the most resource intensive.  These were:

  1. Paying the APC
  2. Reporting
  3. Meeting funder requirements.

Additional points of information gleaned from the analysis included:

  • Three of the four institutions had remarkably similar patterns around the implementation of APC payments.
  • Payment by invoice tends to be the most resource intensive method and has the highest number of activities in the process.
  • Adding suppliers to finance systems can add significant times to invoice payments.
  • We can infer costs in the order of £50+ per simple APC for these comparable institutions, although this doesn’t account for problem investigation or incomplete data (the ‘Counting the Costs of Open Access’ report estimated £81 for directly attributable costs to research organisations.
  • Other groups doing analysis around the APC payment process may find the Functional Family Tree useful as a starting point for breaking down the activities.

We did find Functional Cost Analysis a struggle, simply due to the dispersed nature of our group.  FCA has its roots in engineering and manufacturing and is designed to identify where to target further investigation and improvement in a process.  Next steps will be approached from a LEAN methodology, and may include work around:

  • Use of pre-pay and credit card payments to lower payment costs
  • Evaluate required frequency of some tasks (for example checking and reporting)
  • Automate manual tasks e.g. compilation of reports
  • Training lower grade staff to perform some of the tasks

An obvious but important finding evidenced by the report is that the larger the RCUK grant, the smaller the administrative costs and time for each APC payment.  There are clear economies of scale.

Project update March 2015

We have been working steadily away on our project, despite the radio silence on this blog!  Most of our attention has been taken with the Functional Cost Analysis evaluation of the APC payments process, gathering data from the Universities of Bristol, Cardiff and Exeter to see where there might be room for efficiencies in terms of the cost, effort and number of activities from various payment methods.

fft

Above is the Functional Family Tree for APC Payments, which came from a detailed analysis of the workflows from each institution and input from the Jisc Monitor team.  Time and effort were recorded for each function and sub-function, giving us an idea of what was the most resource intensive.  These were:

  1. Paying the APC
  2. Reporting
  3. Meeting funder requirements.

Additional points of information gleaned from the analysis included:

  • Three of the four institutions had remarkably similar patterns around the implementation of APC payments.
  • Payment by invoice tends to be the most resource intensive method and has the highest number of activities in the process.
  • Adding suppliers to finance systems can add significant times to invoice payments.
  • We can infer costs in the order of £50+ per simple APC for these comparable institutions, although this doesn’t account for problem investigation or incomplete data (the ‘Counting the Costs of Open Access’ report estimated £81 for directly attributable costs to research organisations.
  • Other groups doing analysis around the APC payment process may find the Functional Family Tree useful as a starting point for breaking down the activities.

We did find Functional Cost Analysis a struggle, simply due to the dispersed nature of our group.  FCA has its roots in engineering and manufacturing and is designed to identify where to target further investigation and improvement in a process.  We’ll load our report here on the blog shortly with more detailed reflection.

Other work we’ve been doing has centred around APC payment methods.  We will shortly be releasing a Good Practice Guide on APC Payment with Credit Cards, looking at the advantages, limits and issues around using card payment.

What next from us?  Here are a few outputs to watch for before June 2015:

  1.  Blog post on APC intermediary services
  2. Blog post on access/excel for recording APC spend
  3. Using Credit Cards for APC payment
  4. Off-setting and APC payments
  5. FAQs on APCs for publishers  (with the RLUK OA subgroup by the end of March 2015)

Initial questionnaire for Functional Cost Analysis baselining

Interview schedule for GW4 Pathfinder project 1.2

To baseline the current costs of the payments process for our Functional Cost Analysis (FCA), we need quite a detailed understanding of the whole process – the departments involved, the activities within the process, the staff who perform them, costs (including staff costs), the purpose and requirements for each activity.

To address this an interview schedule (attached) exploring the tasks  within the payments process of each GW4 institution was devised and completed during individual interviews with the Librarians involved in the process at each institution.

A flowchart of the APC payments process for each GW4 institution was developed from this information. We plan to use a second questionnaire for staff working on the process to obtain cost information.

 

Pathfinder update

Like many UK HEIs, the GW4 Universities have been busy over the last few months compiling policy and finance compliance reports for the RCUK.  The last sixteen months have been a steep learning curve for us all, working through processes, learning the quirks of finance systems, working with academics who are also on a learning curve in terms of open access.

In our spare time (?), we’ve met for a baselining workshop  to build understanding of where each of us is on the journey (to use RCUK speak!), experiences so far and thoughts on work to be done.  We are pinning this on a framework using LEAN methodology, and during the first workshop we looked at who our customers are for this process, what they want, areas of waste currently hampering efficiency, and a bit of crystal-ball gazing with our ‘to-be processes’ thoughts.

Our colleagues at Exeter have started work on looking at the issues surrounding third party intermediaries for APC payments, building on the work on the Jisc APC project.

We’re also looking forward to our colleague Liz joining us in Bath from the 8th October.  Liz will be focussing directly on this project, and we expect to have much more news and experiences to share once she gets her feet under the desk.  For example, one of the first outputs we’ll see is some work on Functional Cost Analysis – how much is it currently costing us to process APCs in terms of administrative effort.  This will give us a control to measure against at the end of the project.  More work in this area is ongoing via the Jisc Monitor project, and several other of the Pathfinder projects are working on similar analysis.

Baselining workshop

The first step in looking at administrative workflows and activities has been a workshop finding similarities and differences in OA payment processes and workflows between the four GW4 universities – Cardiff, Exeter, Bristol and Bath.  The workshop, held on 29/07/2014, was facilited by a colleague with Lean SixSigma experience.

Introduction to project

The overview of the day was to look at what we do at the moment (as-is process); think about who our customers are, and what do they want; where is the waste or non value-adding activity; and what should the process look like (to-be process).   The framework for our discussions uses a Lean approach to maximise value and eliminate waste, based on 5 Principles:

  1. Define value-add and non value-add (according to the customer)
  2. Map the value stream, eliminate waste
  3. Establish process flow
  4. Shift from push to pull systems
  5. Strive for perfection

Realistically we probably won’t achieve anywhere near principle #5  but we did do some aspirational thinking towards the end of the day in our ‘to-be process’ session.

As-is processes:

A representative from each institution gave an overview on their APC payment activities.

Prioritising the issues outlined by each representative, these are:

  1. Licencing – ie. CC-BY, checking by publishers would help; at least 50% of items have a problem with the licence
  2. Finance – lots of checking/double checking; double handling; setting up of vendors/payment schedules/ large invoice approvals.
  3. Publishers – many changes for business models; compliance and responsibility for authors?

 

Who are our customers (not ordered):

  • Funders
  • Authors/Academics
  • Publishers
  • Internal stakeholders (operational and management groups, university senior management and reporting line managers)
  • Finance or payment office (including purchasing/procurement)
  • IT people (ie. CRIS, rrepository, systems)
  • Research Office (pre and post award)
  • Admin support in departments/colleges (often devolved)
  • Subject Librarians (advocacy) and other Library staff/colleagues
  • Readers or the end users of the research / other researchers / businesses

What do our customers want?

  1. Authors want minimum administrative burden, maximum impact, high citations!
  2. Publishers want low admin; money(!); users with pre-pay accounts – licencing and money are contradictory issues for publishers.
  3. Funders want value for money, greater impact, many are finding increased accountability from the government, transparency agenda, they are looking for compliance with their policies.
  4. Internal reporting/management want us to be complaint with funders so as not to jeopardise future grants; quality measurement; watching involvement of women/ECRs; statistics to inform institutional policy and strategy.
  5. Finance office want to be compliant with audit requirements; new work should fit in with standard processes and have complete information; sometimes want to circumvent the library (ie invoice direct from author/publisher); not be overburdened when adapting to our systems.
  6. IT want specs in good time as they can’t always react quickly. They want to understand the processes to support us, and prefer a full unchanging specification on any systems developed.
  7. Research office want research information and statistics, tending towards broad brush strokes (versus ‘obsessed with detail’ [library!!]). They want funder compliance and need to provide mechanisms to help with reporting.
  8. Subject Librarians/library colleagues want a simple message, they want to feel supported for difficult issues and kept informed (dislike feeling that academics are communicated with outside of their channels).
  9. End users want easy free access to a broad range of information. The licencing should be clear and open, ideally information found on the publisher website, alternatively versioning made clear.

Our perceived most important customers are numbers 1,3 and 4 above.

What do the 80% care about?

Quote: ‘We are operating in a prestige economy not a cost economy’.

Funders – value for money is important to this customer

Internal management – information provided that demonstrates value for money

(Suggestion to log hours getting data together for reporting (gold/green/reporting time))

Waste:

Discussion on the 8 wastes identified by the Lean Six Sigma methodology and examples:

  • Defects (rework, chasing between customers)
  • Overproduction (recording more information than is needed)
  • Waiting (waiting for next step ie. time between requisition and PO due to approvals)
  • Transportation (movement around the supply chain, ie. unnecessary movement of forms)
  • Inventory (amount of pre-payment, build up of forms before processing)

To-be process:

These are things to keep in mind when thinking about ‘to-be processes’:

  • What’s worthwhile doing? – ask our customers (ie. the authors/academics)
  • Aim for ‘one piece flow’ or small batches (not always achievable)
  • Parallel processing – avoiding single point of failure, removing bottlenecks
  • Work layout
  • Multi-skilling
  • Modular design – forms or systems, standardisation (typically reduces error)
  • Error-proofing – trying to ‘break’ potential ideal processes (poka yoke) – cheap, quick and visual / simple ie. checklist.

Thoughts from ‘to-be processes’ list:

  • An ideal process is where the Library receives the invoice first.
  • Pre-pay accounts have been questioned as the cash is with the vendor before the product has been received.
  • Publisher invoicing – batching by time or number of APCS as a way of introducing efficiency
  • Automatic systems where the publisher sends metadata and fulltext file
  • Validation of paper forms – would a checklist or colour-coding help? (training and guidelines)
  • Licencing – where is the power in the relationship? Authors, journal/publisher, payments?
  • Action: to exchange lists of publishers and numbers of APCs (RCUK reporting) – is there any mileage in a GW4 consortium?
  • Shared services – VAT efficiencies? GW4 coordination of APC payments?  Should we look at pre-pay accounts for this (to be discussed after the action above)?
  • More skills in Libraries to deal with finance. Improved access to finance systems and control over funds to make process more efficient.
  • Reporting – checking licensing is a very manual process. Publishers to report to say they’ve done what we’ve paid them to do?  We need to look at error proofing to stop problems to get this right.  We need to reduce re-work.
  • Reporting to different customers is time consuming (push and pull). Should we be doing bespoke reports to each or give total reports to all?  Desire for RCUK to notify of standardised core list for reporting data.

 

This brainstorming is reflected in the stream-of-consciousness capture below.

brainstorming at workshop July2014

Our next step is to look at capturing a baseline cost per article – more on this shortly.