I’ve talked quite a bit recently about retrieving useful management information from sources other than Talis Alto. I’d like to add one more to this list: Talis Bridge.

Talis Bridge (for those not familiar with it) is in essence an adapter or go-between: it enables devices (such as self-service terminals) that understand the SIP2 protocol to talk to the LMS database directly.

Most of the key data from Self Service transactions can be reported using Talis Decisions: for example the loan transactions done at a self-service machine can be reported just like a manual loan – indeed, to the database the structure of such loans is just like that of any other loan, The usage of particular machines can be monitored by configuring the self service machines with unique operator IDs, and then filtering a loan transaction report by operator.

This works well for many purposes but it is not possible to monitor failures this way: i.e. situations where a user went to check an item in or out, but was unable to do so for some reason. Many SIP2 devices have their own reporting, but clearly it is not possible for them to augment the reports with other data known to the wider LMS.

It is however possible in principle (although at present a slow manual process) to combine data from the Talis Bridge logs with other data in Talis Decisions. Here is an example:  

Because the LMS, knows more about the borrower (age, course, active borrowing history for example) and the item (type, format, Dewey etc) it is possible to segment this kind of report much more deeply within Talis Decisions, and start asking questions such as:

• What is the age profile of borrowers who have trouble?
• Do we need to improve our library orientation sessions for post graduates (because they have an abnormally large number of failures)?
• If users fail to check an item in or out, do they normally go away and come back later, request a manual transaction or just give up?
• Do we need to improve the marking of items where loans are restricted (because we are seeing an abnormally high failure rate for that item type)?

There are lots of possibilities, and for many libraries this might be a “nice-to-have” rather than a “need-to-have”, If you have any views on the usefulness of these data, please do comment on this blog or e-mail me directly.