Showing posts with label smartsm. Show all posts
Showing posts with label smartsm. Show all posts

Sunday, 31 January 2010

Improving stock management

diagram: lending stock life cycle from procurement to withdrawal and replacement

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.


Friday, 18 December 2009

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.