What do we need from an LMS? (Part 1)

This session focused on attempting to define a Library Management System (LMS). The session started with a round-table discussion looking at the specific elements that would be needed make up a successful LMS. We asked people to think big, and not too specific. We used the example of wanting points for discussion such as ‘Is discovery part of the LMS?’ rather than smaller changes that could be considered tweaks to existing systems, for example  ‘I wish issuing could be slightly adjusted’. We also asked people to think about what an LMS was for, and whether could we manage without an LMS in the modern academic library. We asked if any of the essential tasks performed by an LMS were being carried out elsewhere in a university, perhaps using other systems. We also asked if there were any elements unique to the LMS that were essential for the working of a library.

Despite being a large group, the discussion was lively from the beginning. The main point, identified for discussion at a very early stage, was a clear distinction between the services an LMS supported on one side and the the actual technology, modules, system ‘package’ wrapped up as an LMS on the other side.

The discussion quickly identified systems as separate from functionality and workflows/tasks. We used the term ‘essential elements’ to describe the tasks that needed to be performed when managing a library. These essential elements were not, necessarily, tied to being performed within the LMS. Participants made the point that many of the tasks and workflows could be supported by systems within a higher education institution (HEI) and not just by a conventional LMS. However, the important point was made that integration is key in managing library services. For example, book acquisitions could, theoretically,  be made via the purchasing workflow of a finance system. However,  if done this way, the workflow supporting the purchase, receipt of items and cataloguing  would need to be full integrated to support the core library service task of getting resources to library users. The point was also made that the acquisitions workflow, as needed by a library service, may not be fully supported by a standard institutional finance system. Such a system may well just not be flexible enough for this work.

By the end of the discussion, we had identified the following essential elements:

  • Acquisitions
  • Circulation
  • Cataloguing
  • User records/accounts
  • Interlibrary Loans (maybe – the jury was out on this one!)
  • Discovery
  • Delivery of content to users

The other important strand of thought to emerge in the round-table session was the actual system or systems needed. Flexibility and agility were the absolute key requirements here. Although there was much lively discussion around what would and wouldn’t be needed to manage the libraries of the future, everyone agreed that our best guesses could well turn out to be wrong. What we need is a flexibility and agility to support as yet un-dreamed of options quickly, easily and efficiently.

A popular suggestion was to go down a route of modularisation, where capsule functionality could be connected into whatever was currently needed. This was quite a practical point to raise early in the proceedings. However, the mood of the workshop participants, right from the first session, was very practical, focusing on exploring whether a shared LMS would actually be a feasible of way of working.

After the initial round-table discussion in part one of the first session, we moved on to part 2 of that session. For part two, people formed four smaller groups to discuss what they would want from an ideal LMS.

>> Next section: What do we need from an LMS (part 2)?

Leave a Reply

Your email address will not be published. Required fields are marked *