Key model based systems engineering takeaways for all companies
As product complexity increases and recalls rise, companies are learning that recognizing problems after they happen isn’t as valuable as recognizing them before they happen.
But accountants need justification for such a plan and its expenses. If you can point to a case that shows what could happen when there’s no plan, you can easily convince them why it’s a necessity.
In this series, Mark Sampson explores why companies need model based systems engineering. In part one, he discussed how model based systems engineering can help companies identify potential problems before they happen. In part two, he shared the story of how a company without a plan allowed household humidifiers to wreak havoc on its business. Here, he introduces takeaways from the story that all companies can use.
Model based systems engineering takeaways
As you read this story, you probably thought it couldn’t be true. But then you probably thought of your own story.
The goal here isn’t to poke fun of building maintenance, company bureaucracy, electrostatic plotters or anything else. I want you to see the downstream effects and expenses that short-term thinking can have on cost savings and ROI. Looking at only the expensive up-front investment in an industrial grade humidifier system was a valid decision, but it didn’t take into account all foreseeable downstream ramifications or costs.
Model based systems engineering optimizes the whole system. This includes cost, reliability, the environment, ergonomics, maintainability and the other myriad of items that impact the problem. Taking these factors into account helps companies identify an overall optimum solution.
For example, in our story, how much money could the company have saved if it had eliminated electrostatic plotted drawings and incorporated electronic drawing delivery?
But the company couldn’t afford the upfront time and money to systems engineer a valid approach. It made a decision not to invest in a solution that would’ve avoided an additional 50 or 100 times the costs in the long run. Instead, it got bandage solutions, slipped schedules and countless amounts of lost productivity — all of which is real money.
Organizations that have been there and done that gain enough experience to put processes in place that avoid these problems. They consider model based systems engineering part of doing business, like insurance to avoid future problems.
But the value of systems engineering goes down over time. Think of it like a teeter totter on a playground. As children, we learned that leverage was on the farthest reaches of the board. If we lay the product timeline out like a teeter totter and think about leverage in a project, we see that the most leverage is out front and early in the lifecycle.
One of the most valuable systems engineering takeaways companies should know involves a childhood favorite.
This is why Simon Ramo (the R in TRW, Inc.) said this in 1997 during his INCOSE keynote speech: “All the really big mistakes on a project are made the very first day.”
After all, the greatest leverage is at the beginning. As the project moves on, you lose leverage whether or not you have systems engineering. It still has value across the project lifecycle, but it loses value the longer you wait to apply it.
If you’re familiar with LEAN thinking and its eight wastes, let’s add an additional waste by paraphrasing management guru Peter F. Drucker: there’s no greater waste than efficiently doing something that shouldn’t be done at all.
Postscript
As a fitting final tribute to the humidifiers at site closure, we threw them off of the office building roof.
This concludes our introduction the model based systems engineering.
About the author
Mark Sampson is a product manager/evangelist on the System Driven Product Development Team. He is responsible for integrating systems engineering and requirements within the product lifecycle management (PLM) business at Siemens. His work with this integration helps customers enable systems engineering and its requirements to participate and influence all aspects of product development.
Note: Parts of this post previously appeared in Volume 30, Issue 8 of Computer originally published in 1997. More information on that article may be found here.
