Thursday, March 31, 2011

Management

Yale's School of Management is situated just across Sachem Avenue from the Peabody. To walk there from my office takes only a few minutes, but I always thought the mental journey would be a lot longer. For me, the gulf between museum and management was perfectly illustrated by the Nissan GT-R that is often parked on Hillhouse outside the SoM. I don't know whether it belongs to a member of the Management faculty, but that is not beyond the bounds of possibility. On the other hand, I can be absolutely sure that it doesn't belong to anyone from Peabody. We're not really a GT-R sort of place.

Having spent some time over the past few weeks talking to management researchers, I'm thinking it's high time I revised my impressions. No doubt there are some aspects of management theory that are quite esoteric, and others that are quite lucrative, but the people I've met seem eminantly sensible and quite down to earth. But that may be because they are also engineers.

Time to back up a little. The regular reader of this blog (and yes, there is one) will be aware of the ongoing efforts to digitize biological collections across the USA. If you're not and you're interested, click on the tag marked "digitization" at the bottom of this post and you'll find out more than you ever wanted to know. One of the major challenges to mobilizing the mountain of collections data is the sheer size of the task. No-one really knows how many natural history specimens there are in American collections, but 1 billion is probably the right order of magnitude. Museum workers have been databasing their collections for over 20 years now and have captured less than 10 percent of this material; there's not much evidence to show that the rate of capture has improved significantly, so clearly some new insights are needed.

Last week, I got to go to a meeting in Chicago where we brought together a group of collection managers, curators, software designers, and - yes - management scientists, to look at what we might do to improve matters. There will, in due course, be a report (which I will post here for those who are interested) but for now I will offer up a simple explanation of why we need help.

Part of the reason for holding the meeting in Chicago last week was the presence of Automate 2011, the largest trade show for industrial robotics. My colleagues and I tend to get quite excited by robotics, because of our touching faith that machines may replace the staff that we can no longer afford to employ. Going to shows like Automate tends to reinforce that impression, as you watch robots manipulate tiny and often very fragile objects at blinding speed, using machine vision to identify, sort, and process. Then you ask the sales guy and find that you can apparently purchase one of these babies for less than a Toyota Camry (I don't know what's going on with the car analogies today - sorry). There were those among us who were already reaching for our checkbooks.

This is why you need to go to tradeshows with an industrial engineer. "Not so fast," says my new friend Brian from MIT. Installing a robot in your collection is not so easy. First, they're not plug and play. Each unit requires a bunch of operating software and support hardware that costs as much, if not more, than the robot itself. Even if you have all of the pieces, setting it up can be a considerable challenge - a whole masters thesis can be written on the process of simply delivering the object to the robot, which is different for each application. Most of these robots are designed for dealing with industrial components, which are generally highly consistent in size, shape, etc. Even the wrinkled corner of a herbarium sheet would be sufficient to shut them down. Robots can deal with variation, but it massively increases the cost. And when they break down (which happens not infrequently) you need a trained operator onsite to deal with the problems. And robot specialists are not cheap.

Consider Amazon. You might assume that a massive company like this, with a pretty standard operating model (they have big warehouses full of books that they need to deliver to buyers) would be highly automated. "Not so," says another new friend, Don from the University of Chicago's School of Management. Amazon has people pushing carts up and down the aisles of its warehouses. The reason why is that books are highly variable - in size, shape, and weight. By the time you've factored all of this into your the design of your robot, it ends up being cheaper to employ people to do the job. If this is a problem for Amazon, how much more of a problem will it be for us.

So what can we do? Well, I'm not going to tell you everything now, otherwise you'll never read the report, but here's one lesson we learnt. In any workflow, including specimen digitization, there are a number of stages. Each of those stages will have a maximum rate - the fastest speed at which an object can pass through it. The stage with the slowest rate is the bottleneck and it will determine the overall speed of the process - however much you increase the speed of the other stages, you can never go faster than the speed of the bottleneck. For this reason, all of the rest of your workflow should be designed to feed the bottleneck - it should never be idle. Bottlenecks are usually the most expensive part of the workflow - in digitization, for example, it might be the camera or a scanner. So in designing any project, the first task is to find the bottleneck.

This is process management 101. But how many of us sit down and model workflows when we start a collections project? And how many of us write these up and publish them so that, as a community, we don't reinvent the wheel for every new project we start? Technology - software and hardware - will undoubtably provide some of the answers to the challenge of collections digitization. But the best start might be to get a more structured understanding of what we actually do.

No comments:

Post a Comment