“No Way!” barked my department chief engineer when I suggested that the true customer of engineering is operations. “I despise those SOBs and there is no way in the world I would ever consider them my customer,” he emphatically pronounced.
I had spent the past two years investigating the causes of our “quality escapes”—our term for issues found by customers in the field. Our team suspected that poor (if any) communication between the designer and the supplier or factory was a primary cause of defects in the field. If so, our designers were creating plans with no more than an assumption that the factory could make or assemble the part. For most parts, there is no issue and because of this the designer is too often lulled into a confidence that talking to the factory is not required.
Putting a spotlight on the ramifications of this mindset, I’m reminded of a situation early in my tenure at the Earthmoving Division. A high-profile product launch had quickly turned from “christening the ship” to a “train wreck.” When hundreds of parts begin meeting each other at the assembly line at production volumes and takt times, mole hills actually do become mountains. Small issues that made assembly difficult mushroomed into line stoppages. We were forced to deploy engineers to the line for months and trace issues deep into the supply chain. Issues that could have been resolved during design were now impacting our ability to meet commitments to end users in the high-quality way they had come to expect.
Allen Ward, PhD, LPPD expert and author of Lean Product and Process Development, highlighted the need to treat manufacturing as a customer of engineering as an essential element of product development:
“We don’t make money until customers buy what comes out of our plants. Development exists to create operational value streams. Operations is our customer. We should listen to and serve operations just like external customers.”
Obviously, this is easier said than done. Day in and day out, factory managers are paid to build and ship product. Seldom do they have time to discuss a future product with the development team. In my own experience, getting engagement in early concept and development activity was like pulling teeth. It wasn’t that the manufacturing teams didn’t want to be involved, but rather the issue of what gets measured gets done. There was little reward in expending manpower on a project that may not hit the factory floor for another three years.
It was no different in dealing with external suppliers, except they were more friendly because they wanted to win the business. In the case of an external supplier, they would be asked to participate in projects even before the business had been awarded and could even still be competing for the business. Suppliers, too often, would commit to designs, including cost points, that may or may not be achievable. Like the factory, purchasing people were more focused on meeting the demands of the day than with future programs.
I would emphasize that there is no nefarious intent on the part of the factories or suppliers. They are simply doing the best they can with the resources they have to ensure parts get shipped today and that there is something to build tomorrow. Executives beat on the front-line managers to ship more product and to remove material, variable, and period costs from the value stream. There are never rewards handed out to a team or factory whose costs went up year over year.
So why does this matter and what can be done to improve things?
Working well across organizational boundaries is a secret to lean value streams. One in which the wastes of rework, hand-offs, and wait times is minimized so that end users are happy to trade their hard-earned dollars for the product that our factories produce.
Back to the “train wreck,” not only did engineering need to pull people off value-added activities to rework issues found during production ramp-up, but purchasing people were refocused to address inbound quality problems; i.e., parts that were not meeting print specifications as they entered the factory. Furthermore, valuable operation people had to rework machines once design and supplier issues were resolved with new parts. Ship dates were missed, and scheduling and logistics teams had to shuffle schedules of inbound material and finished product delivery dates. Perhaps worst of all, customer commitments (end users) were missed and had to be managed to prevent migration to competitive products.
Unfortunately, this is not a once in a career type of story. Recovering within a crisis; e.g., a train wreck, becomes a visible issue that requires an “all hands on deck” mentality. Teams leap into action and are celebrated for heroic efforts and hours dedicated to righting the ship. This “forced teamwork” is nonnegotiable and accepted by all organizations. Firefighting is recognized and rewarded.
LPPD offers a better way. By employing LPPD, the development team converts firefighting into fire marshalling. Responsive actions occurring late into the development cycle are moved to planned activities early in development. People in all parts of the value stream can do things right the first time, rather than rework perhaps multiple times on the road to production. In the world of development, this requires intentional behavior that is often counterintuitive and, even more challenging, counterculture.
By counterculture, I mean that traditional thinking will be altered in a way that will be uncomfortable for many. It took months for the Chief Engineer I mentioned earlier to come to this realization. It was not by me making him believe this statement, but rather application of lean principles that led him and his team to the conclusion that operations is the customer of engineering.
Traditional thinking has engineering create a design and hand it to a supplier to make. Lean thinking involves the supplier as the design is created and gains insight from the maker of the part. I often told my team that we want to design into the “sweet spot” of the supplier. This means doing things the supplier is good at already. The goal is to have perfect parts coming into the assembly factories. If we ask a supplier to manufacture a part that is difficult for their processes, we have significantly increased our project’s risk profile.
It is not just the engineering department that has to think differently. Purchasing must change the way they work with suppliers. In the normal environment, suppliers are managed primarily to deliver at the lowest cost possible while hitting challenging quality and delivery targets. Suppliers want and need the business. They typically agree to what the customer; e.g., purchasing, is asking them to do and figure out how to make money along the way. In the case of a new part, they will agree to the design handed to them and when problems come up along the way, they will request changes to the part late in the development process and often after production launch.
I recall discussing the print release status on a new machine program with the lead project engineer. I asked if the supplier had seen the latest version of the production drawings. The answer was troubling. “I don’t have time to talk to the supplier,” stated the leader. “They will ask for changes as we ramp up for production, and we will revise the drawings then.” The timeline was more important than doing things right the first time. You might be thinking I should fire the engineer. It is not his fault. The management culture created an environment where this behavior is not only tolerated but celebrated. Hitting your dates becomes a badge of honor. Until recently, this behavior had not been traced back to the quality escapes in the field. People behave within the reward system the leaders of the company create.
To embed a more collaborative environment between engineering and operations, both assembly factories and suppliers, teams containing purchasing, manufacturing, and engineering were created. The teams were broken down by systems such as light fabrications, heavy structures, powertrain, controls, electrical, etc. These teams were responsible for both new and current production, which provided a feedback loop for new designs from the good and bad elements of today’s products. The combined disciplines working together caused the product (design) and the process (design) to make the products to be addressed concurrently. This is fire marshal work.
During a visit with a company that had embedded LPPD, I pushed back on the concept just to test my own beliefs. “How do you know this LPPD stuff works?” I inquired of an engineer who had a visible outer shell that signaled he had been through many firefighting activities in his career. “Because people are happier!” he belted out as if I were the only person in the room who didn’t know the answer. I did know the answer and simply wanted someone to reinforce what I felt the moment I walked into their building. It was like a fresh breeze on a sunny spring day.
As these lean principles were applied within my own company, in a span of less than five years, quality improved by more than 50 percent while warranty dropped by $90M. New product introductions were no longer firefighting events but methodical marches to the marketplace with few surprises.
Operations is the customer of engineering. Ensuring that designs can be made by suppliers and those parts assembled in the factories is the most important element of development once the external customer need is met. Moving reactive firefighting to proactive fire marshalling is where the true heroic behavior happens. Allowing teams to do things right the first time rather than iterating with rework after production saves time and money and will create more engaged employees from the design centers to the shop floor.
