Process vs. System Improvement
A couple of days ago I sat in my favorite book café and worked on a Current Reality Tree. Opposite from where I was sitting, a couple with a small child sat down. The man sat at the right table. The woman sat at the left table. (Right and left are from the position of the viewer, i.e me, throughout this article.) After a few minutes, the man rose up, tried to go between the tables, and hit his head on a lamp hanging from the ceiling.
The figure above shows the tables where the couple was sitting. If you look closely at the picture, you won't be surprised that a couple of minutes later, when the man rose up again, he hit his head, just like he did before. The lamps are not centered over the tables, so rising up to the left of either table is likely to result in a bump on the head.
The third time the man rose up, he instigated a process change. Instead of trying to go between the two tables, he went to the right of his table. This time, he didn't hit his head.
Most people would be satisfied with this. Indeed, we do such process changes all the time, little accommodations to work around the imperfections in the systems we are part of.
However, changing just the process left the couple with unsolved problems. One problem is that if there is a small process variation, for example, if the man forgets to move to the right when he rises, he is likely to bump his head again. Another problem is that the woman might bump her head too. As you can see in the picture, the lamp above her table was also off center.
At this time I pointed out the problem with the off center lamps to the couple, and suggested that they should move the tables a little bit to the left. The man grinned (a bit sheepishly) at me, and moved his table, but not the other one. Nor did the woman.
This is very interesting behavior. The man recognized a possible systems improvement when it was pointed out to him, and moved the table. Both he and his partner failed to apply the same solution to the table standing next to it. This is a failure to generalize a solution. They could see the problem with the rightmost table, yet did not recognize that there was an identical problem with the table to the left.
Eventually the couple left, without either one getting bumped on the head. The woman, though she did not implement the systems improvement, i.e. moving the table, did rise carefully, so as not to bump into the lamp above her table.
When they had left, I moved the leftmost table, like this:
In general, we are much better at adapting processes than we are at improving systems. On the other hand, improving systems tends to yield much better results. In this case, all customers sitting down at either of the two tables will enjoy a head-bump free stay at the café. Maybe the café will attract a little bit more business as a result. Customers receiving head-bumps might be less likely to return.To me, the story illustrates one of the core properties shared by TOC and Lean. Both aim at improving systems. That is why they are so effective. It is also one of the reasons why they are so hard to implement.
Comments
Extending that thought to ask what do we get from a systems analysis that we don't get from a process analysis it seems to me that such things as emergent behavior of a system that depend on component interactions (such as swarm behavior) might be a better example.
To give an example: many IT consultancy companies are shifting to agile right now, or have shifted recently. Agile methodologies can, if implemented correctly, increase the ROI on projects several times.
However, management usually fails to update measuring systems, contract models, switch the organization from push to pull, etc. All of these things are necessary to actually bring home more money.
Time-and-materials contracts don't bring in more money if you cut project duration by 80%. They bring in less money. Still, managers usually think you are a bit funny in the head if you tell them they must switch to new contract models, and train their sales people to use them.
Making developers fill in time reports is useless, but the practice continues even though it sends management worthless information. (Keeping track of OE is useful, but that can be done without the distorting effects of detailed time reports.)
Throughput and DIP measurements, which are essential, are not used. If used internally by the teams, the information is not reported back to management.
Try giving a manager information about queue build-up. S/He is unlikely to know what to do with it. Some just get angry.
Value Stream Maps? Never heard of.
Most improvement efforts fail precisely because they do not address systems and systemic causes.
As you point out, swarm behavior can be used to illustrate the need to examine a system to understand the behavior of its parts. For example to understand the behavior of a bee in an bee colony, we must understand its relationship to the rest of the colony. To understand the behavior of a colony of bees, we must understand its environment. The swarm will behave differently depending on the weather, availability of food, etc.
However, the idea was to use a recent experience to illustrate the difference between process and systems changes. Right now, I can't recall any swarm related personal experience that illustrates the difference so clearly.
If you were to engage with the owner of the cafe, you might be able to suggest something a little more permanent. I'd be thinking of making the lights a bit higher, or painting marks on the floor to remind the cleaners where the tables should go.
Maybe I'm just looking at a slightly bigger system.
Some time after I wrote the post, someone had moved the tables back to their original position.
I suggested to the café owner that they should raise the lamps a bit higher, which they did. It solved the problem. However, that solution was not a viable alternative for the couple in the anecdote.
Me being me, I also had a Crawford Slip brainstorming session with the café personnel, investigated other cafés in the area in order to find out what their strengths and weaknesses were, did a TLTP analysis/synthesis, and wrote a report. Some of the suggestions were implemented, and it turned out pretty well.
And yes, I asked beforehand whether it was okay to do that, as a way to say thank you for excellent service during the many, many hours I have spent there while working and writing. The café personnel have grown quite used to their odd customer over the years, so they accepted.
I am going to that café in a couple of minutes. It's a nice place.