Showing results for 
Search instead for 
Did you mean: 

Integrated Systems's all about leverage

Siemens Visionary Siemens Visionary
Siemens Visionary

seesaw1.jpgEven kids already know where the most leverage is on a see-saw. It's a subtle SE training technique to educate children on Systems Engineering!-)

I recently 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.

sewsaw2-withproject.jpgPlacing a project timeline under the see-saw, you can see where the most leverage is--at the start of the project (or even before). Applying leverage on a project is the job of Systems Engineering. The earlier Systems Engineering is applied on a project the greater the leverage.

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 d...). 

Q: Do you have any examples of leverage (or lack thereof)?

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).


ASICS.jpgA comparison study of 21 ASIC Design Projects 

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… “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.


Solution Partner Esteemed Contributor

Nice article @MarkS. Well organized and I can see the benefit. Good job!

Siemens Dreamer

Interesting post, and while I don't (directly) disagree, I'll challenge you to expand your definition of scrap. I'll ask (for the sake of encouraging discussion), what if the board conformed to requirements, but customers chose not to purchase it? Isn't it scrap if the boards sit on store shelves, and are left unpurchased? In the retail market, the customer never provides requirements at the beginning of the project; the customer makes a binary decision as to whether or not to purchase, after the product is conceived, designed, manufactured and distributed. We can conform to requirements, and still build unsellable scrap.


So sure, there is value in moving upstream, but the Systems Engineers are not at the headwaters (it would be the customer, or their representative... say the marketing group).


And of course customers change their minds as to what they find valuable, given sufficient time, and if there is too much time from the development of requirements to the delivery of the product, we will still be creating scrap. And how do you handle innovation, where the customer can't even imagine today the product that they will love in the future? As Steve Jobs said: "How can the customer be right, he hasn't seen what I've invented yet?"


So...  I see the story is an example of increased manufacturing scrap due to a lack of upstream design clarity, but I will challenge you by claiming that this is the description of a subsystem, not the system as a whole. Deming, Juran, Ohno, etc. will tell us that to understand a free-market economic system we need to address the customer's perception of value. And to be truly efficient, we need to understand that their perception will change over time.


I guess my point is that MBSE, SysML, etc. models do not increase product value, but they may help avoid decreasing value. (Scrap is decreased value.) But true value comes from corporate agility. This story does not adress whether Systems Engineering makes the organization more agile.


Thanks for providing a forum for my academic (i.e. irrelevant) discussions.

(And I am an academic. I like to challenge SE's because I am one ^_^   )

Siemens Visionary

...thanks for the comments.  My blog post on 'where the project starts' talks to this in regulated situations.  You are right that highly regulated products have it easier as they are handed a set of requirements and sign a contract to deliver against to get paid.  Of course commercial ventures don't have it that easy making it more important to understand the customer up front, stay in sync with them, dealing with disruptions, et al.  


As an academic, how do you teach commercial systems engineering practices? 


Mark S.