Lean Transformation

"Lean Manufacturing" has bothered me ever since it became a fad 10 or so years ago. Seemed to me that it was just a catchword for rediscovery of the fundamental principles of manufacturing efficiency discovered and widely adopted in the first 200 or so years of the industrial revolution. Add to that a spin for new computer applications, some revisions to leadership and HR methods for a new generation of educated workers and a whole bunch of new buzzwords and acronyms. Thus were empowered a new hoard or management consultants and purveyors of books and training seminars.

"Reduce waste during the design stage" ......Insist on near net shape part designs, minimum part count and statistical tolerancing at the early design stage. (EEEEUUUUU.....that is so last millenia)

It's still the same old stuff rediscovered by people who don't want to know how to manufacture and would much rather have someone else do it for them.

Ed Weldon

Gotta go with you on this one, ED (GA!) - most of this crap was what you used to hire a manufacturing engineer for.

Sillier and more expensive was when we all got marched into training for Six Sigma - for software. Sample size = 1, statistical significance = 0.

Marketing had a Simplified Six Sigma too - heaven forfend anyone be left out.

Fortunately I enjoy statistics.

You guys are probably right about the history of Lean but the corporate-wide application of Lean Thinking has been long over due.

Most corporations are no longer run by CEO's with engineering backgrounds but rather finance, law, accounting, etc. They are after results of a different type. To disparage current Lean efforts because they are not unique in the engineering field is counter-productive.

BTW, if you read the threads in many Lean and SS forums, you will see that there is a huge resistance to implementing the principles by upper management. The question should not be is it a rehash of old ideas but rather why aren't those principles part of the DNA of modern American business in general.

Perhaps engineers need to start taking over the executive suites! :)

Perhaps engineers need to start taking over the executive suites! :)

Heaven forbid, I have even gone to lengths to stay out of management, but... that said

That said, some things are just dumb; and we ran 1200 software engineers through Six-Sigma. You do not manufacture software. Despite the engineer title, currently software is more crafted than engineered. Even by the best organizations.

You manufacture a lightbulb - by the millions. SS matters a lot. But despite millions of lines of code, SS really doesn't apply effectively. We should have taught them more about coding for aviation. Never lose track of your essential product and the skills required. And the need to train effectively.

Meanwhile we were watching essential aviation skills being retired and didn't have the money to train new ones because our schedule and budgets were eaten with SS. I had engineers who would have killed for a class in FMEA/FMECA. Now you almost cannot hire an experienced FMEA/FMECA engineer because we forgot what we do as an industry and got roped into these fads.

So it isn't that I hate lean or SS, they have their place, just want us to use the right tool for the job. No single tool fits all problems.

And before we get off on duplication and waste in software, these efforts are almost always run by someone who knows nothing of the process. We have thrown our own software people at the same problems since the fifties, (yes, 1950s) and the error rates, rework rates, bug rates, requirement churn rates have effectively not changed in all that time.

So effectively, since 1950 not one single tool, college major, software suite, new language, new method, new means of eliciting requirements has made one damned bit of difference despite spending one hell of a lot of money.

And this according to the software gurus of our time. I spent all holiday reading.

Now if you want to get some effectiveness out of change; MAKE the employees own their processes, reduce the overhead to revamping a process, and get rid of SOX. It is estimated you could save 15% across the board - every business - if you got rid of making EVERY EMPLOYEE down to the stock boy responsible for the CEO behavior.

I have signed innumerable statements, at some personal liability, that I would turn in any CEO guilty of malfeasance. How the hell would I know?

So sorry for the thread hijack, sorry for the rant, and totally off-topic - except that silly bastage is going to promise them great savings in software development - and it ain't happening. Even if you call it lean. Good software is expensive. You want aviation quality software it is even more expensive. Get used to it.

/RANT

(...I am now throwing in the large piece of raw meat...)

There...that's better.

I agree with many of the statements you made. Certainly the point about lousy S/W development practices. All the SS in the world won't help it; SS is definitely the wrong tool. However, I am sure the C-level folks beat their chests and said "now we will have no problems because we made EVERYONE go through the SS training".

But forward thinking developers have changed their ways and began implementing practices based on Lean and Quality, namely Agile and SCRUM. These methods not only make the code writers responsible for their daily goals but also build in test scripts and good documentation so that individual components of the software package are known to work as stand alone items. Then these various components are compiled in multiple iterations of the semi-complete build. The end result is far fewer bugs when the alpha is compiled.

As far as losing the competitive edge because fundamental training is not offered, that is the result of the myopic vision of the corporate heads; only looking at next quarters' numbers rather than investing to build the breadth and depth of professionals needed to carry the company down the road 10, 20, 30 years and more.

Gotta disagree with-

"So effectively, since 1950 not one single tool, college major, software suite, new language, new method, new means of eliciting requirements has made one damned bit of difference despite spending one hell of a lot of money."

A lot of good has been created and implemented since then. But we are always behind the curve instead of in front of it. However, most of these initiatives have been ground-up instead of top-down.

Finally, I no answer for unfunded mandates like SOX. These government decreed handcuffs have created real headaches across the board, especially healthcare.

I've got to believe you software guys know what you're talking about; but you're way over my head. Are you talking about the efficacy of a "lean transformation" in the way software is developed?

The proposition statement for this topic contains the following lines at it's end:

"Roy said Al-Ashaab and his research team will focus on reducing waste during the design stage. Such waste includes instances when engineers rework or duplicate their projects. He added: 'The consortium will try to develop processes and software prototypes that will help people design better and reduce design lead time."

Seems to me that this is about improving the engineering development process using "lean" approaches and then incorporating the improvements in an engineering management system via software tools.

After reading some of the Wikipedia articles on "Lean Manufacturing" it seems to me that it boils down to eliminating waste of resources in the processes. I can see where this applies as well to engineering work (hardware, software, technical documentation, etc.). Eliminate waste in the engineering development process and you both save money and shorten the time to next stage of the project and perhaps, if the engineering work is good you improve the efficiency (time and money) of future stages of the project like manufacturing and all the way out through the product life cycle. Sounds great.

But I've got a feeling here that Dr. Gadalla needs to back up a little bit. From my experience in the commercial capital equipment industry I'd say the level of production effiiciency in the creation of "engineering work" was comparable to where manufacturing was at the beginning of the Industrial Revolution. In the early 1800's they were just beginning to grope with the concepts of interchangeable parts (with complete and toleranced drawings), and labor saving powered production machinery was primitive needing a high level of operator skill. (sounds like today's 3d CAD)

Now look at the typical engineering department of today. How often does the engineering boss get a complete and well executed product specification from the marketing folks or whoever else that decides on new products? And if there actually is such a spec how many times before the engineering work is complete does it get changed? And how often are the changes in the form of little more than a phone call, meeting minutes or a written memo rather than a formal revision?

How often does the company play fast and loose with what can be designed with a certainty of performance instead looking for some genuine invention or downright miracle to erupt out of the engineers and their work? (note a good engineering manager's rule of thumb that there should be no more than 5% of the technical work in any project that is not 100% predictable in its outcome)

And then there is the "sell the first complete prototype" syndrome which leaves the engineers with a way down level lash-up lab queen to complete their testing on, the software guys tearing their hair out and no resources to get a timely replacement. (Oh, you guys have your CAD models; what do you need a hanger queen for?)

How about the "system integration" part of the well documented engineering project schedule that becomes a great black hole time and money sponge and the source of a 25% redesign of the product.

Another fun time is when the marketing people begin to discuss the new product with their favorite big customers and come back to engineering with a list of "must have" features to add. These things grow on the product (and the software) like mushrooms wrecking the cost targets and all the "ability" goals so carefully planned for. Like mushrooms they are the only visible part of an insidious underlying organism.

Still another problem is the time crunch caused when each successive layer down the chain of command imposes a tighter schedule to hedge its commit dates to its superiors. This creates situations like prototype part suppliers working overtime weekends to meet Monday deliveries for parts that are needed until Friday.

There is the human cultural polarization between company departments that mess up communication links in a way that is pretty seldom seen in monolithic manufacturing organizations. This is the kind of inefficiency that requires leadership, not software, to fix.

I could go on here but suffice to say that Dr. Gadalla has bitten off a tough project that will require a lot more than software to fix many engineering departments and make them more efficient.

Ed Weldon

Further reading on Lean Manufacturing, for those wishing to go deeper with this topic: "Agile Manufacturing: An Industry Expert Speaks to the Local Engineering Community" - click here. - Larry

I read this three times but I'm still having trouble understanding a lot of it.

Ed Weldon