Like many libraries these days, my library is planning a migration to a new integrated library system/library management system. And, like many libraries these days, the software we're migrating to moves us from a module-based system that puts an emphasis on functional areas to a system where functionality is more process-based.
This movement toward process-based functionality has me thinking more and more about systems thinking and how libraries are, generally speaking, not great at it.
When I think of systems thinking in libraries, it is helpful to me to think of a system as a set of component parts that interact in a dynamic way. There are a lot of projects and ongoing processes in my library whose component processes "live" in different functional areas. A systems thinking approach would suggest I should look at the whole of a process or project, rather than only looking at the processes that make up the components of the system I'm responsible for. By looking at the system as a whole, I can work more flexibly and collegially with the people who are responsible for other component parts of the system.
I think that moving toward seeing the whole of a process or project rather than just the component parts that make them up is not always a natural inclination for people who work in libraries. We often tend to see the world as processes that are our job and those that aren't. It feels so unnatural, I would argue, that libraries are starting to hire project managers to help coordinate the component parts of a project or are designating someone to serve as project manager. Having someone serve as the hub of a project or process from which all of the component parts flow in and out is helpful when it comes to time sensitive, deadline-based projects. But I would argue that adopting a systems thinking mindset should be the responsibility of everyone in the organization.
One of the goals of the Unified Library Scene is to build better relationships--especially between functional areas within libraries. It's hard to do that, though, when you have a 'this is my job and everything else isn't' mentality. Having that mindset makes establishing areas of mutual concern really difficult and it makes having a shared understanding about the relationship between component parts of a process. Yes, cross-departmental projects and processes can run smoothly and efficiently without a commitment to a systems thinking approach. But there's only so far those projects and processes can go if those responsible for the component parts aren't interested in the work happening in other component parts.
As I've been thinking about how my work will change as a result of my library's adoption of software based around processes, I've been thinking more about how I can move out of a "component parts" mindset. One thing I've found valuable as a starting point is looking at a process that I'm involved in that crosses into multiple departments and talking to people about their component part tasks. Who is responsible for the process before it gets to me and what are the choices they make that impact my work? Who picks up the process where I left off and how do the choices I make impact their work? I don't need to be the center hub of the wheel from the very start, but a good place to start is understanding the spokes closest to me.
The ways that our libraries work best is when we aren't ruled by the silos that our functional areas create for us. Instead, we work best when we think of not only our place as component parts in the system, but when we think of the system as a whole.