Architectural Lessons from Factories: Inventory Hiding Inefficiency

Bottleneck:  Let’s say you run a factory with three stations.  Those three stations will never work at exactly the same pace.  The slowest of those stations is the bottleneck.  There will always be a bottleneck, by definition, but you want to keep the stations’ speeds going at about the same rate.  If the bottleneck station starts getting much slower than the others, you take a look and see what the problem is because it slows the whole system down.

Buffer: One thing you can do to improve the efficiency of the system, given that your stations will always be a little bit slower or faster than each other, is have a holding bin or buffer between the stations.  That way if station 1 happens to finish a task before station 2, he doesn’t have to stand there holding it and waiting for the next guy to be ready.  The guy at station 1 just puts it into the holding bin.  Similarly, if station 2 finishes before station 1 is ready, she doesn’t have to stand there waiting until the other guy finishes his task.  She just reaches into the holding bin and grabs the next widget.

Too much buffer: But once these buffers become too big, it’s easy to not realize that the various stations are growing out of sync with each other.  For instance, if the buffer between stations only holds three widgets, then once station 2 gets through all three widgets in the holding bin, she’ll realize something is wrong with station 1.  What’s wrong?  Why am I going so much faster than you?  Is something broken?  Has he had a heart attack?

But if the buffer is huge, Station 1 could be limping along at half speed for days before anyone notices.

This is one of the ideas behind how Toyota does business, and why their factories are so much more productive than their competitors.  

They run a very “lean” process, such that there is just enough buffer between stations to keep things moving along, but not much more.  Any problems with the system are therefore immediately made apparent and fixed.

What parallels can we draw from for architecture, to make the design process more efficient?

Our inventory is information, not widgets, and we are drowning in it.  I’ll use myself as an example.  I typically have five or six change orders I’m working on at any given time.  So whenever I’m waiting on a phone call from an engineer, for example, I just switch tasks to the next change order.

The problem is that, by bouncing around between all these different tasks, it’s easy to not even notice that five days go by before I get a phone call back from that engineer I was waiting on.

There’s something wrong with the system when Station 1 takes five days to get something to Station 2.  But because my buffer of inventory was too high, I didn’t even notice.

The solution is to create a queue.  If I reduce my buffer holding bin to two, (in other words, if I only work on two change orders at a time), I will be much more aware of gross inefficiencies in the system.  Then we can work on them.

The rest of the change orders wait in the queue until I get finished with one of the two I am working on.  As the queue grows, we use this as another very visual indication of either inefficiencies in the system (a severe bottleneck) or that the system’s capacity is too low, compared to demand.  In other words, they need to hire another person.

Possible causes of sever bottlenecks in your architectural factory:

  • A team member doesn’t the experience or training to do the things he or she is tasked to do — usually easy to fix with some training and mentorship.  But the next question is, why was he afraid to speak up and ask for help?  This leads me to the next possible bottleneck…
  • A team member is just a plain old jerk, so people avoid calling him.  I’ve had several consultants like this, and it really slows down the process.
  • There could be a technology problem.  Someone is having severe computer problems and can’t respond or complete drafting, and they were afraid to bring it up because the budget is to tight or because the IT person is a pain to work with.
  • There is some key person like the head “designer” or medical planner who needs to make a crucial decision, but is off traveling to drum up new work.

You all deal with these inefficiencies, but by letting the inventory level stay too high you mask the severity of the bottlenecks.  By limiting the work-in-progress and requiring the rest to stay in a queue, you don’t actually get the work done slower—it just seems that way because it’s more obvious.  And that’s the idea!

Notes

  1. oscia posted this