The difference 1mm can make...

[adrianh]

I changed a laser cutting plan this morning by shifting two lines 1mm over. You might say "So what?" The business lessons learned from this are really interesting.

We were chatting this morning about our workload and that our main problem is not that we don't have enough customers, we got more than enough, but rather that we can't deliver fast enough.

I know that the laser cutting goes fast because I recently optimized my cutting procedure. I also know that the staff work fast. I've optimized so many things....what else could we do?

I asked my staff what takes long to do. They say that nothing takes long because they've devised ways to do everything really fast. So what now, there must be an answer. So we talk a bit more and I eventually ask the following question: "What in your opinion do you think is a waste of time" The one guy explains that the laser cuts a part of the model a little thin sometimes and they remove the offending section and rebuild it by hand. He goes on to say that they do this with 4 out of 5 models but that it is ok because they do the rebuild quickly.

What a revelation.

We chat a bit longer and I discover that their idea of "quickly" and my idea are different things. They consider 2 days to do the repairs to be quick. We grab a model that has not been cut and one that has be cut and we look closely at the issue. It becomes apparent that the problem is a lot bigger than they make it out to be. They actually rebuild the entire back part of the model because they are forced to cut away the left and right rear and that forces them to hack out the middle as well.

The problem is that the laser cut line is too close to the edge and also that the rear end needs a little plate to be laser cut so as to remedy an alignment problem that they have.

Off to the Pc, fire up the CAD software and spend 10 minutes drawing...shift a couple of lines and draw a little plate. Now for a bit of testing. Not a single model has the defect and the little rear plate fits like a charm....problem solved.

You might think so what, a couple of seconds saved here and there. The implications are gigantic. The particular model is made for our biggest customer and we need to deliver very fast. The faster the better because they don't give us a hard time and pay quick.

The business lessons

1. It is very difficult to get to the crux of a problem because we don't always know what question to ask.
2. People interpret questions differently and answer accordingly. The question "Do you work fast and efficiently" is answered in terms of their own frame of reference which is not always meaningful in the bigger scheme of things.
3. The question "What do you think is a waste of time?", in this case, was the trigger to the solution. Could it be that they thought of it because it is a way to have a little stab and also feel vindicated in the idea that the boss sometimes wastes their time.
4. Having clever people who are able to solve problems on the fly isn't always the answer. The answer is to train those people to have a different perspective on problem solving. Rather than solve the symptom efficiently, they should rather concentrate on resolving the root cause. (A bit like the dentist giving you a months supply of pain killers for your toothache rather than doing a root canal on the offending tooth)
5. The solution often lies in making a small upstream change that cascades downstream eliminating lots of problems.

We are quick to say that one should work smart rather than hard. The difficulty lies not in fixing a problem but rather in finding the root cause of the problem and fixing that. We tend to look at a direct solution for a problem and yes, the solution may be a patch but it is not always the right answer. Upstream problem often only show up long after the implementation of the big plan and are often so deeply embedded that they cannot be repaired without major redesign and cost. Maybe the solution doesn't lie in repairing the design flaw nor in fixing the symptom but rather in finding a point in the process stream where a cure would be most effective. I always found software design to be fraught with this type of problem. A system will be designed and implemented only to find that the basic design ideas were wrong. Lots and lots of patching is done to fix all the downstream issues. The client now sits with a lot of spaghetti that nobody really understands any longer because the patches complicated everything. I am of the opinion that to modularize as far as possible is the answer. To design with clean interface boundaries i.e. object oriented programming encapsulation. The last thing of course to remember is that systems and procedures evolve and unlike mother nature where every evolution cycle sits on top of the previous iteration, we are free to design and create revision 2. This revision is not derived from the body of version 1, but rather from the understanding of its soul.