Pre-Covid-19 I attended a Model Based Systems Engineering (MBSE) Workshop at NASA’s Jet Propulsion Labs (JPL) in Pasadena (MBSE Workshop proceedings on google drive), where I was limited to a couple of slides to state my position on a systems engineering (SE) and how models fit into systems engineering. Systems Engineering is all about leverage. Systems Engineering needs to be applied early to get the benefits of the leverage it provides–put another way, the value of Systems Engineering diminishes with time, the later you apply it the less value it has.
My position proposed moving models to where the value is—i.e. up front where the answers can give you the greatest leverage vs models applied nearer the fulcrum where the leverage is small or even the right side of the project in manufacturing and service where system models actually create project drag.
Some of the questions during/after the panel included:
Q: So where does the project start so we can move models there?
A: In the case of highly regulated industries such as utilities, mil/aero, or medical devices where you receive a set of requirements that you need to respond to; in that case, the start of the project is actually before you’ve won the business. To get the most leverage you need to apply the models during proposal response (watch for a future blog entry in requirements about applying wildcatter techniques to requirements during the proposal response phase of a project).
Q: Do you have any examples of leverage (or lack thereof)?
A: How about this for lack of leverage example when a problem is discovered late in product development.
On the wrong side of leverage the cost of late discovery and design redo can be daunting, resulting in work around discussions that leave significant damage in its wake. There is some value in these monuments for future generations like this “Column of Shame” at a major engineering college that serves as a lesson/warning to others when an architecture mistake (or no architecture at all) is discovered too late to correct.
Q: Any idea on the value of SE leverage?
A: The following experience demonstrates leverage…
Out of college I went to work in the high-tech electronics industry, ending up implementing electrical CAD/CAE systems. Somehow I ended up on a tiger team to figure out why our circuit board assembly line had a 55% scrap rate (our definition of scrap was a board that could not be used for any reason when it came off the assembly line). Naturally we looked at manufacturing data where we saw fires that needed to be put out on the assembly line. As pin patterns became smaller, assembly workers weren’t precise or consistent enough, so we went into a project to automate the assembly line—pick and place machines, AI controlled wave solder machines, et al.—a major investment. After firing up the line we started measuring results, with automation the scrap rate went down to 48%.
Pealing the onion back we could see there were more problems earlier in the design/CAD part of the process; board layouts needed to change for pick and place machines, 100mil grids, no more standup components, et al, all had to be considered so we could take advantage of the millions invested in the robotics on the factory floor. So standard component libraries were put in place, rules checkers with workflow handlers to ensure exceptions were documented, etc. Once the CAD layout features were in place, we followed the boards through the process, measured the scrap rate–it went down to 40%.
Pealing it back again, we found engineers were coming down and talking to the layout guys, changing on the fly because of late discovery of issues; we needed to put CAE/circuit board simulation in place to do the analysis up front to remove the turbulence downstream—logic simulation, identify EMI, thermal, and other issues before we get to CAD… CAE tools were provided to engineers, training completed; we followed the process through manufacturing and the scrap rate when to 30%.
What’s ahead of CAE? Systems Engineering. We found that SE work done/not done contributed 30% of the scrap rate through architectural decisions/non-decisions, defining interfaces, constraints set/not set, and the rest of the list (that’s the interesting thing about systems engineering, even not making a decision is a decision).
This journey pointed out if we had spent our time initially on the Systems Engineering—architecture, partitioning, interfaces, constraints, etc. part of the problem we could have avoided 30% of the downstream scrap rate.
You could probably figure out the cost of all the waste/scrap, but they aren’t direct effects, thus one of the problems with Systems Engineering—it’s hard to nail down the monetary value of leverage but we can sure feel the turbulence downstream from those decisions/non-decisions.
There was another study at the time showing the value of SE leverage in ASIC’s (Application Specific Integrated Circuits). The study analyzed 21 different IC’s and the costs associated with them.You can see IC 1 and 19 are of comparable complexity but the labor required to bring them in on schedule are an order of magnitude different (they put more people on the ASIC project #1 to hold schedule).
The study placed the blame on poorly defined interfaces, constraints, and architecture as people went to work on the project (i.e. lack of leverage) leaving project #1 to find its own way and correct the issues late in development while project #19 had the SE work done in advance (i.e. leverage).
Management guru, Peter Drucker put it this way… “ There is no greater waste doing efficiently something that shouldn’t be done at all”. The best way to ensure the right things are being done and they are done right is to make sure the Systems Engineering is done up front where all the leverage is.