Introduction
The Celtic Engineer is a weekly newsletter produced by Celtic Engineering Solutions. We hope you enjoy it. If you have any suggestions for topics, would like to give feedback or want your email added to the distribution list please send an email to [email protected].
Production vs. Engineering
If you have been in engineering for any amount of time you have probably come across the fact that companies do not understand the fundamental differences between Engineering and Production. I will give you a few examples. One company where I worked had a very efficient purchasing department. They cataloged what they bought and you could get something out of stock by writing a request. They would restock long before they ran out so production always had what they needed. But if you wanted something that was not in stock, for a prototype, it could take 2 months to get it to you. We would laugh because after 6 or 7 weeks they would eventually have the part overnighted to us. This was wasteful and frustrating. The problem was that the purchasing department was optimized for production and not an engineering department that was focused on new product development.
There are many programs that are great for production but terrible for engineering. Imagine 5s’ing the engineering department. I can imagine a very clean engineers’ desks with two small rectangular taped areas, one for a pen and a second for a pencil. Then a large taped rectangle for the engineers note pad. At the end of the day they would clean their desk and put everything where it belonged. I am sure, or at least I hope, all of you are chuckling at this. There are, however, some people who would read that and think it was a great idea. Yeah. Well, if those poor engineers did not immediately flee the company, we can only hope the company has a good alcohol and drug rehabilitation program.
Those kinds of activities greatly improve productivity in production but kill it in engineering. Even though that is true there are some very important lessons engineering can learn from production. The use of those lessons, must be applied in a different way to be useful.
Before we jump into the main topic, I want to frame my motivation for you. I have been building a shed in my back yard. It 16’ by 11.5’, so not tiny but not big enough to need a permit either. Last week I finally got to the part of the process where I was nailing the shingles on the roof. I had a smattering of leftover boxes of roofing nails; different sizes, different manufactures and different manufacturing dates. The very last box I used had dull coatings on the nails. They were distinctively different looking from the ones I had used up until that time. Once I started using them, I found they bent very easily. In fact, it was hard to drive them in without bending them. I have decided they were improperly heat treated, or perhaps they missed that step all together. The metal was probably annealed in order to make it soft so that it was easy to from the head. Before shipping though, you need to temper the metal to harden it so that it does not bend when someone is on there roof trying to finish up their shed before winter. In the end I got the roof done but look at the number that got bent. I needed less than 10 nails to finish the job and had to go buy a pound box to do it. Someone did not do their job.
Applications in engineering
Even though engineering is not a production environment, there are lessons to be learned from the bent nails. I am willing to bet that Rembrandt did not have a production line in his studio, but still was concerned about quality control.
Quality in design engineering can take on many forms. They all have one thing in common and that is to reduce the errors that our customers must endure. When we design a PCB for a prototype, there is the possibility to get the wrong footprint connected to our part. This affects our customers, internal or external. It is a mistake and it has consequences.
I have been in environments where it was proposed that we have a check list of things that we go through for every design. This might not be a bad idea, but there is a difference between providing an engineer with a tool and burdening them with a process. There is a balance between reducing errors and having zero tolerance for errors. When you are sending men (and hopefully someday women) to the moon failure is not an option. You must spend the extra time and money to get it right the first time. When you are in new product development the opposite might be true. I have heard, as have you, the meme, fail fast. The reasoning being that the faster you find out what does not work, the faster you can get a product out the door. A new skew is a new revenue stream.
Somewhere in between those two extremes is wisdom that can be applied to engineering. I recently discussed the difference between addressing an issue and solving a problem. And this is where I think the lesson lies.
This can best be shown using an example. You have just made a prototype and found that the footprint was wrong. This was an error, but there are several ways to address this error. You can go into the library and fix the footprint or change the footprint to which the part is attached. That addresses the issue, but it does not solve the problem. The problem is not that the wrong footprint was placed on the board, the problem is that there is no mechanism for screening parts.
Here is an alternate scenario. When a new part is created, it is put in a local library and not in the main company library. Before using the new part, it is printed out to scale and a part is dropped down and visually checked for accuracy. Once the board is made and tested, the parts can be moved into the company library. This is not a perfect plan. It does require extra work and it is not fool proof. It does increase the reliability of the main company library.
This illustrates the difference between addressing an issue and solving a problem. When we solve a problem, we are looking at the bigger picture, how can I keep this from happening again. That solution, as indicated above, must always be balanced with the cost of keeping it from happening. When balance is achieved, life is good.
Final thoughts
This newsletter is sponsored by Celtic Engineering Solutions LLC, a design engineering firm based out of West Jordan and Murray, Utah, which can be found on the web at: www.celticengineeringsolutions.com. We are also on Instagram and Twitter. We will soon have a Facebook page. If we can ever help you with your engineering needs please contact us. You can find the newsletter on the company blog, LinkedIn or in your inbox by subscribing. Send your emails to The Celtic Engineer at: [email protected], with the subject line SUBSCRIBE.
Do you know someone who would enjoy the newsletter? Forward them a copy or let them know where to find it.
