Decisions Blog

Archive for October, 2009

SCONUL Performance Portal

Very often, what to measure can be as problematic as how to measure it. This is an area where the sharing of good practice would seem to have much to commend it

It is mostly relevant to academic libraries, but SCONUL (Society of College, National and University Libraries; well known for it’s collection of statistical data) also has a Performance Portal launched in June 2007. This was an initiative of the SCONUL Working Group on Performance Improvement. The portal has a number of sections intended to disseminate good practice in the management of library performance. There are sections on survey tools such as LibQual. There is also one on Key Performance Indicators (KPIs), although as yet there is little detail in this area of the site.

The principle seems admirable. If you have any experience of performance management in an academic or public library, please do comment on your experience of the practice.

The future of Business Intelligence – what does it look like to you?

A recent article in Information Week identified four key issues (they called them “technologies” but they are more than that) in commerce and industry at large (not just Libraries):

  1. predictive analytics,
  2. real-time monitoring,
  3. in-memory processing,
  4. Software as as Service (SaaS)

Predictive Analytics uses data from past events to attempt to predict future ones. This would apply to things like automated assessment of mortgage applications or insurance claims in order to assess the likelihood of default or fraud. Real-time monitoring cuts the time taken to get relevant data to a decision maker in time to intervene whilst events are unfolding. A speedometer in a car is a very simple example. A more complex example: the doctor in charge of an Accident-and-Emergency unit might have a  display which alerts him/her to patients who are at risk of breaching the four-hour waiting-time target.

I cannot think of situations in libraries where either of these would be cost effective: it would of course be nice to be able to predict (say) next year’s loans or active borrower count, but the usefulness and statistical validity of such predictions would be questionable.

What is your view on this? Do you think that these capabilities have a place in the library world? Can you imagine likely scenarios or examples? Please use the comment facility to add your ideas.

The second two (in-memory processing and Software as as Service) are more promising. We looked at the Software as a Service model last year as an adjunct to Talis Decisions. It didn’t seem wholly cost-effective at that time, but it is an area that we are keeping under review. We are in the early stages of evaluating a possible in-memory extension to Talis Decisions. This might allow a more interactive style of “what-if” reporting.

Again, please do let us know what you think. Do you see a place for either of these in practice in the library world? If they were in place, what kind of things would you do differently?

Self-Service Terminals reporting

In recent months, a number of folk have raised questions about reporting around the usage of Self-Service terminals. There seem to be a couple of issues; What (to report on, regardless of means) and How (at a technical level). In this post I’ll attempt to set out some ideas on both.

What to report (and how to use the reports)

As ever with management reporting, the best place to start is what outcomes are considered desirable, and what management actions the recipient can actually take to achieve that desired end. The desirable outcomes are in this case fairly intuitive: to increase efficiency whilst maintaining staff morale and retaining borrowers. Actions that management can take might include:

  1. Make changes to Self-Service Terminal siting
  2. Make changes to staff planning (e.g. more staff on when manual transactions high, fewer when self-service transactions predominate)
  3. Make a change to opening hours (e.g. if it is found that the use of self service holds up later in the evening)
  4. Make a business case for more self-service terminals
  5. Take steps to re-activate customers who may have been scared off by the introduction of self-service.
  6. Reassure staff
  7. Organise staff training in the use of staff pads (workstations) or in encouraging borrowers to switch from manual to self-service transactions
  8. Run experiments (e.g. assigning a staff member or volunteer to hover around a group of self service terminals at peak times to help Borrowers get over the initial techno-fear)
  9. Organise undergraduate education
  10. etc. etc. Please do add other ideas as comments

Many of these actions can be supported by monitoring transaction volumes by site and by terminal in a given time period. There are many ways that these data could be displayed. Here are some examples:

Self Serve 1

This first example gives an overall feel for the extent of Self Service Terminal utilisation by site

  • Site A shows a healthy pattern : Staff Pad (Staff Workstation) and Manual transactions are low
  • Site B does not have a Staff Pad (or if it does, it isn’t being used). Also it either has insufficient terminals, or the terminals are being underutilised
  • Site C is quite out of balance. The self service terminals are little used

Self Serve 2

This example shows the number of loan transactions by hour of day through the day. It might feed into staff planning.

  • The peak in Self Service transactions around 3:00 coincides with few staff issues at that hour . This might bear further investigation. Are the staff busy on other tasks? Have afternoon lectures just finished or a local school just come out?
  • It also looks like this site is open for self-service issues longer than for staff issues. The slight rise in self-service issues around 19:00 (7:00 pm) suggests that if the site was open until (say) 9:00 p.m. then issues might continue.
  • Note too that I’ve added a drill filter on the Site of Loan to this example (top left). If you select a site in the drop down, the chart redisplays with just the data for that site. (This is of course not available when viewing the report in Excel or PDF).

Self Serve 3

This example shows the utilisation of individual terminals, staff pads and human operators by hour of day. You might want to add a drill filter on the site if the number of terminals is large.

  • It is pretty clear that most of the terminals are under utilised. The issues at terminals A, C, E & G together add up to only a few percent of the issues at terminal B.
  • Those issues that do occur at the less-used terminals all seem to occur in the morning: they are hardly used at all after 2:00.
  • It would be worth asking staff to monitor Terminal B between 1:00 and 3:00 to see if there are frequent queues at it. If so, it may be worth putting a notice on it like “There are more self-service machines located…”

These examples are not exhaustive. For example, Borrowers who lapsed around the time that terminals were introduced and who never used self-service terminals might be candidates for a marketing effort emphasising that help is available to learn how to use the new terminals, and that the old issue procedure are also still available.

How to do it

Again, there are a number of ways of generating reports like these. There is one key issue however – in order to get data down at the level of the individual terminal, it is essential that each terminal and staff pad have it’s own unique operator ID, and that these operators are set up in Talis Alto. Any Operator IDs that are not set up within Talis Alto will not show up in the Talis Decisions reports, even if they are configured correctly in Talis Bridge  At the end I provide an alternative partial solution if these are not set up correctly.

The three examples above were all individual report tabs within one Talis Decisions document. This was done using Web Intelligence in Talis Decisions XI Release 2. All three reports were based on the same single query. The core of such a query might look like this:

Self Serve 4

You can embellish the query with item and/or borrower details, but the query will take longer to run, as for each loan a look-up will be required on the linked item and/or borrower data.

It is usually essential to restrict the date range for a query like this. If the query is run with no date filter, or for a very long period, the query may take a very long time to run and might not complete at all. If despite restricting the date range to (say) a week, the query still takes a long time to refresh, it would be worth raising the issue with your account manager, because this may indicate an issue with your Talis Decisions set up.

You will note above that there is reference to a Terminal Type. This is not data extracted by the query; it is a variable that uses data from the query. The basic principle is to say that if the Operator ID is in one range (or one set of values), it is a self-service terminal. If the Operator ID matches another set of values, it must be a staff pad etc. The variable is defined in this way:

Self Serve 5

The variable formula used in this illustration is

=If(Match([Operator];"T*");"Self Service";If (Match([Operator];"ST*");"Staff Pad";"Manual"))

This example assumes for illustration that:

  1. all the self service terminals are configured so that the operator starts with a “T”, that
  2. all the staff pads are configured with an operator that starts  “ST” and
  3. anything else is assumed to be manual.

You would of course have to amend this formula to suit the terminal configuration in your library.

If your terminals are not configured with unique operator IDs, or if the operator IDs are not known to Talis Alto, then an alternative which will give you some information is a query like this:

Self Serve 6

The Loan Activity Breakdown returns values such as

  • Child project loan
  • Housebound
  • Manual discharge
  • Parent project loan
  • Public renew
  • Seen issue, renew or discharge
  • Self-issue
  • Unseen renew

The exact values may vary from library to library, but the underlying codes are the same: all SIP2 transactions (apart from Talis Message) will have a LOAN.ACTION_ID = “CLIS” which will probably be labelled “Self-issue”.

What Can’t be done currently

Only successful Self-service transactions are recorded in Alto. If a user tries fruitlessly to self issue an item, fails, gives up and goes away in frustration without telling anyone then Alto will not have a record of it. The Talis Bridge logs do contain data on failed transactions and it would in principle be possible to extend Talis Decisions and Talis Bridge to allow reporting on failures.

Is this something that you feel is important? If so, please help direct the Talis Decisions and Talis Bridge roadmaps by commenting on this post enabling us to gauge demand..

Any other comments/suggestions based on your needs or experiences with self-service reporting would also be most welcome.