Libraries and COVID-19

IFLA provides a pretty comprehensive overview of the impact of COVID-19 on libraries and the known factors involved in returning to something like business as usual.

https://www.ifla.org/covid-19-and-libraries

Learning from experience

When you're doing any sort of serious developmental work, whether it's solving a problem or exploiting a new opportunity, you have to start by defining your preferred outcome then look at all the possible options for getting you there. One of the things that constantly dismayed me when working in public libraries was just how limited "all the possible" usually was, and that these limitations were often imposed as a matter of principle rather than practice. Often summed up with a look of complacent contentment and the mantra: "Ah well, you see, they don't work the same as libraries." I still bump into this thinking quite regularly on the lists and social media, often as a dogmatic statement along the lines of "Libraries have got nothing to learn from…" This is, of course, the veriest nonsense: libraries can learn a great deal from other business operations, if only the reasons why adopting a particular policy or process would be a bad idea in a public library context (and that aren't "Ah well, you see, they don't work the same as libraries.")

The other reason why it is nonsense is that although a business operation may be very different to yours some of the operational functionality requirements may be very similar, or the same. There's no particular philosophical or ethical difference between opening the public doors to a library first thing in the morning and opening the public doors of a shop, for instance.

The exciting thing about not imposing any constraints on where ideas can come from is that you can often find alternatives to the organisation's "default setting" that are cheaper and more effective to apply.

The responsibilities in my last job included a transport management system called Tranman. Very generally speaking it was used to manage the council's fleet of vehicles and the jobs done in the vehicle workshop. Some of the jobs done in the workshop were part of the routine maintenance work included in the service level agreements with the council departments using the vehicles. A lot weren't: repairs necessitated by accidents or driver abuse were chargeable extras and the workshop also did a lot of private repair work, services and MOTs as part of the operation's income generation. Extremely different to the business operation and purpose of the public libraries I was also supporting.

They had a problem. A lot of the jobs were taking ages to complete and invoice on the system because they were missing information about the parts that were issued to them. Even worse, some jobs had been completed and invoiced without including the rechargeable costs of the parts. This was playing hob with their cash flow and making the accountants cross. So we had a look at it and basically the situation was:

• There was a manual process involving somebody trying to catch up with a pile of paperwork at the end of the month
• There was a technical solution which could automate the stock issue but wasn't being used

What was needed was for the parts to be issued to the jobs in as close to real time as possible and that wasn't going to be done manually from the paperwork.

We had a long, hard look at the technical solution. None of us were big fans. It was hard work to get set up and running and, frankly, was over-engineered for its purpose. On paper it looked great:

• A piece of software on the stores manager's PC generated barcoded labels for each part, the barcode including the appropriate part number and bin, together with a human-readable description.
• The parts bins were labelled up accordingly.
• When a part was to be issued to a job the store man entered the job number into a PDA, read the appropriate barcode and entered the number of items being issued.
• The PDA was then plugged into a console attached to the store manager's PC and the data uploaded into Tranman.

In reality it wasn't so hot:

• The barcoded labels soon got scruffy and unusable.
• We could make the barcodes on the labels as big as we wanted but the descriptive text was always tiny and difficult to read, especially in some of the darker corners of the store room.
• The keys on the PDA were very small (6mm across), which was difficult enough for me with my never-done-a-stroke-of-hard-labour-in-his-life delicate fingers and not a lot of fun for workers who'd spent years bashing their finger ends on bits of metal on cold Winter's days. The incidence of input error was high.
• Uploading the data was a bit hit and miss at first: it took quite a while for us to iron out the problems and making sure the solutions were properly packaged into the virtual application. (I for one was praying nothing happened to that PC as I wasn't confident we wouldn't have at least a few of these problems again with a new deployment of the software.)
• It wasn't easy to see where and when something went wrong. The lack of transparency meant that you couldn't do any quality control to make sure that the right parts actually were being issued to the right job.

Something had to be done. 

We looked at various somethings: we spent far too long trying to sort out better barcode labels; then we had a fruitless quest for a more user-friendly PDA that could do the job. Over the next few months, in between a pile of other pieces of work we were doing with this system, we tweaked this process as best we could but in the end it felt more like we were working through levels in an arcade game rather than getting anywhere with improving the process and addressing the cash flow problem. By this stage I was thoroughly fed up and went and had a sulk in my tent. On reflection it was apparent that all we had been doing was following the same ploughed rut over and over again. 

We'd let our problem-solving be dictated by the "solution" rather than either the problem or the desired outcome.

So I looked again. And wondered why the issuing of parts to a job in a vehicle workshop was very much different to the issuing of library books to a borrower…

The solution I came up with was cheap, not especially elegant but did the job and could be seen to do the job. There were two elements:

• A standard barcode reader, same as you'd see in a shop or library
• A folder containing sheets of labels including all the information needing to be entered into the job record:
• The description of the part in a large, readable font
• The part number as a barcode (using the "3 of 9" font)
• The bin number as a barcode
• The store location as a barcode

The process was:

• The request comes in for the part for the job
• The stores man gets the part then opens the job record in Tranman
• The part number, bin number and location are input by reading the barcodes from the appropriate sheet
• The only manual input is the number of parts
• The parts are issued to the workshop

For out-of-hours working the process was:

• The request for the part is recorded on a paper job sheet
• The fitter working on the job gets the part
• Next working day the stores man issues the part in Tranman as above

Getting a working test sheet turned out to be a bit of a problem because initially I was doing it in MS Word and the formatting it imposed was disabling the begin and end codes of the barcode (an asterisk *). Jacking it in and doing the job in Wordpad gave us some test sheets we could use to demonstrate proof of concept. I used Crystal Reports for the final print out of all the parts.

Sadly, this is as far as I got with it by the time I was leaving. We'd checked that each step should work as expected but we'd not given the process much hammer and inevitably there'd be some snagging to do. One thing I'd have liked to have done, given the time, would be to modify the Crystal Report so that the first few pages were limited to the high-volume items, to save the stores men having to routinely wade through so many pages.

So that's how I applied a bit of standard public library functionality to a problem in a completely other environment.

So what are the takeaways from this?

• Don't mistake differences in business operation with differences in operational functionality. In this case, issuing an item in real time is issuing an item in real time.

• If your problem-solving energies are being devoted to the solution perhaps you've got the wrong solution.

• To solve a problem you have to know what problem you're solving and the outcome you desire of the solution.

Demonstrating the Return On Investment: Renew, Refresh, Recycle

With the best will in the world, all of our catalogues will have a few skeletons in the closet. Human beings being human beings there's always the odd book that's been missed by the stock editors. They're not necessarily the liability they seem to be. They shouldn't be on the open shelves as items of current import, to be sure, but there are creative ways of using them, together with a selection of the "respectable" components of your reserve stock to make useful and informative display collections.

Public libraries hold a lot of the national back-catalogue of books. This is generally held to be important as far as fiction is concerned but, aside from a small proportion of 'classic' texts, not non-fiction. After all, out-of-date information is useless, right?

Not necessarily.

Imagine a view of the history of Germany through the eyes of somebody who didn't know that the Berlin Wall was ever to come down. Or go up in the first place. Or that Hitler would rise to power in 1933. Or... Well you get the idea.

It's easy with history, isn't it? What about science? The history of science is littered with the dead bodies of fallen ideas and Laws Of Science. I remember being baffled at university (yonks ago) by the civil war between the cladists and the phylogenetic gradualists (you'll have to look them up) - they were talking about aspects of the same idea, just using different language with all the intemperance of theologians disputing one or other heresy. A generation before it was the geosyncline versus plate tectonics debate. All a bit specialist and arcane, eh? Not really - all the time that the aeroplanes were grounded by the Icelandic volcano our newspapers were filled with diagrams of plate tectonic processes. How would they have been described fifty years ago?

And as for technology... It struck me recently that the world I grew up in as a very small child in the 60s wasn't wholly dissimilar to that of my parents' childhood (excluding powdered egg and the Luftwaffe). The Swinging Sixties didn't much reach our way, save for the Beatles and beehive hairdos. My brother was born into a world of colour television. My sister-in-law can't imagine a world without computers and MTV. Children born today would struggle with the idea of not having a mobile 'phone with a camera and internet access and umpteen thousand channels and applications. And we've still not got those personalised jet packs and robot butlers.

One of the reasons why primary resources are important is that they are uncontaminated by hindsight. Hindsight always has 20:20 vision. We know what happens at the end and that inevitably colours the narrative. History tells us which were the blind alleys, the discarded values, the paradigm shifts. And hindsight always imposes the prejudices and values of today onto the thoughts and actions of yesterday.

There is a case for our provided access to the unsullied product once every so often in "What we used to know" promotions to give us a better understanding of the historical context. It's not always enough to know how we got here, it's sometimes important to understand what happened along the way.

Improving stock management

I mentioned a while back that we've bought into smartsm and that we want to do a lot with it. To give you some idea of the scope of our ambition, the only part of the lending stock life cycle that we don't see being directly influenced by smartsm is the actual process of procurement. Once the item's arrived it'll be included in the smartsm processes.

Which isn't to say that we're going to be doing everything at once. Realistically, the first stage is going to be the running of reports for stock that's either sitting idly on the shelves or else perhaps being physically overworked and needing replacement. We should then be able to move on to working up an evidence-based transfer régime that ensures that stock is moving to meet local demand rather than somebody's best guess (or long-standing organisational tradition).

Talking to other smartsm users it seems that it takes the best part of a year to build up enough data and trends analysis to be able to start using it effectively in the stock selection process. This is fine by us: the fact we can use smartsm at all for this purpose is icing on the cake so we don't mind waiting.

Between stock analyses on Dynix, smartsm reports and issue statistical reports on Dynix we should be able to take a more holistic approach to stock selection and location; make individual items of stock work harder by moving it on when it has fulfilled the local market; and demonstrate that we’re getting value for money.

At the moment we are only likely to be using smartsm as a lending stock management tool as we have chosen not to record evidence of use of reference stock. There is no technical reason why evidence-based stock management cannot be applied to reference stock: we could use Dynix's "In-House Use" function to generate the usage data for this stock.

The answer's always in the question

I'm probably the only person in the known universe who's going to be doing this but it's worth my noting it down as a reminder of the general principle.

We've bought into smartsm, which is an evidence-based stock management tool. We're working on Dynix, which provides a ton and a half of really useful data but which provides far too much detail for everyday working. The idea is that we can use smartsm to pull together the data into reports which can be run by front-line staff who can then take whatever action is appropriate. (The idea's a bit more and a bit bigger than that, but that'll do for the purposes of this narrative.)

Dynix is an old library management system and interoperability isn't it's strong suit, by a very long chalk. The good news, though, is that it's very easy to do snapshots of any combination of data and then export that out as text. Being an old Pick system, the data's not held in tables like you'd see in an SQL database; the best way I can describe it is that for all practical purposes the data's held suspended in mid air connected together by bits of string. These bits of string ("dicts") are one of the most powerful data manipulation tools I've had the pleasure of playing with and I'll miss them greatly when we eventually move onto a new LMS. They do three jobs:

• They define which piece of data you're looking at;
• They define how you're going to see the data; and
• They can link the data in one file to that in another file.

So, for instance, the dict called BARCODES in the bibliographic record file called BIB reports the data found in the first line of a BIB record in columnar format 16 characters wide. The dict called L-COLLECTION reads the data in the first line of a BIB record, uses those barcodes to look for the appropriate records in the HOLDINGS file, reads the code in the fifteenth line of each record, translates the code(s) into the appropriate collection labels and reports these in Title Format in a column 40 characters wide. And once a dict is set up and shown to work OK you can forget about all the intermediate steps and just get the data.

So what's this got to do with smartsm?

We need to do a monthly extract of our catalogue data providing the bibliographical data for each item plus its location, collection, current status and its use. And smartsm need this as comma-delimited data in a set format so that they can map it against their reporting processes. Most of which is easy enough to do: if you tell me that you need the title of each book up to a maximum of 100 characters it's literally less than a minute's work to do. You want it comma-delimited, it'll take a minute or two to remember how to impose a constant comma in front of the reporting data. And for the most part it really has been that easy. In some cases I've wanted to aggregate the data into something more useful, for instance we have umpteen item statuses providing different reasons why these items are not available for loan (being repaired; being boxed up for transfer to another library; audio items bought then held back under the terms of the performance licence, etc.), which are usually useful when you're looking for a particular item but drag in a bit too much confusing detail for reporting purposes, so I set up a dict that just reports these as "not available." A few bits were more complicated but I got there in the end.

And then there was the date format.

Date formats are a pain in the arse, no two ways about it. The data extract had to provide the dates in a particular format, which isn't any of the date formats available on Dynix. I spent six weeks trying, and failing, to write a dict that jiggled the components around a bit to give the right format. I was beside myself with frustration.

On the bus home one night I realised I'd been a prat.

We need comma-delimited data, right? If I downloaded the entire catalogue database and stuck a comma at the beginning and a comma at the end this would be treated as one piece of data, one column wide and one row deep. I didn't need a dict that juggled the day, month and year data. I needed a dict for day, a dict for year and a dict for month. With a comma before the day data. Which was five minutes' work the next day.

Note to self: in future, pay attention to all the question. The answers come easier that way.