WHAT is Systems Engineering?

[Kims Robot]

I've been happy to see over the last couple of years a few threads pop up on Systems Engineering within FIRST. I've been a Systems Engineer since my first job out of college, but with every company treating the role slightly differently and some not even formally defining the role, I've often struggled to explain to people "what exactly it is that I do around here"...

Anyways, a colleague just sent me a great article on the 9 Laws of Effective Systems Engineering. The "Laws" listed are beautifully concise, and I like that the paper is written in a less-academic sense. I've seen a lot of fancy papers about SE that really throw a lot of jargon around but don't really do much to really make SE tangible. This one really seems to hit the nail on the head. Some of the details of the paragraphs get a little jargony as they head towards promoting model based systems engineering and a few of the diagrams are "scary" but if you read (on average) the first two or three paragraphs of each section, they apply to the role of the Systems Engineer in general. I am not incredibly knowledgeable of model based SE, but so much of the rest of the paper is valuable that I wanted to share it.

The Laws listed are:

Law #1 - Begin with the End in Mind
Law #2 - It Doesn’t Help to Solve the Wrong Problem
Law #3 - Insight is the Goal
Law #4 - The Model is the Main Thing
Law #5 - To Catch (Design) a System, You Have to Think Like One
Law #6 - It’s All about Relationships
Law #7 - Even a Set of Views is not a Model
Law #8 - Choose the Representation that Best Suits the Audience
Law #9 - Systems Come in 3s

And the intro says so much:

For the manager seeking project success, the design team seeking to deliver a solution, and the customer seeking an answer to their needs, systems engineering is critical. It is through the application of sound systems
engineering practices that the ultimate solution can be crafted to hit the mark while minimizing or eliminating unintended consequences. It is the systems engineer who maintains the systems perspective on the underlying
needs and value proposition throughout the quest for a solution. It is the systems engineer who tracks the interaction of the system with its environment and works to prevent any unplanned, detrimental interactions
that might result from the system design choices made along the way.

However, it is because of the items listed in bold that the job of a "good" systems engineer is so transparent. Often we see "heroes" in the other engineering fields - the electrical engineer who comes up with a brilliant solution to the failed ESD circuit, the mechanical engineer who comes up with a way to interface to the broken shaft on a motor, the programmer who comes up with a workaround for the failed sensors. But where are the Heroes in Systems Engineering? There so rarely are any, because it is so critically important for the Systems Engineering to be done in a proactive way. Systems Engineering just cannot be Reactive.

So many design teams struggle with a lack of Systems Engineering. No one can put their finger on exactly what is "missing", but things just seem to fall apart when they don't expect it, or the team is in a constant firefighting mode because they didn't have "the big picture".

Often I struggle with justifying the expense of keeping a full time, or even part time systems engineer on a program when they aren't "producing" anything. My highest value added is not the Interface Document I write, nor even the System Requirements I derive... its the day to day consideration of the issues that may come up, the anticipation of the problems that could arise, the recognition of the team/design headed towards solving the wrong problem, the constant customer focus that causes the Systems Engineer to see that the solution won't meet the customer need. "I don't care that the customer WROTE that they want this, we know they NEED that." I laugh when I have a conversation internally, and I can nearly quote word for word what the customer's answer will be when we ask the question in the future. Its my job to get in their head and figure out what they need, understand every detail of their application, and then help drive our system to meet that.

The Classic Engineering Swing Example says so much. The "What the Customer Really Needed" is what every good systems engineer should be focused on, and should help the team focus on. I'm sure you could fill each of the cartoon boxes with FRC robot concepts as well.

And How true is this statement for many of you?

Components are developed in isolation from one another and then cobbled together to form a system. This means that the synergistic results which are the point of the system design are either lost or badly compromised.

Sure that drivetrain design looked great in your CAD model, but when you tried to mount an Arm to it, oh no!! Moving the arm into a half deployed position caused interference with the gear box! Or "Oh that battery fits perfect into that belly pan!" but when you actually implement it, there isn't enough room for a hand to get in there and unplug the battery!

I "Begin with the End in Mind" with everything I do, and ultimately, every aspect of this can apply to FIRST. I hope each of the teams learns to develop their Systems Engineering prowess, regardless of what they call it... Team Leader, Robot Coordinator, Master Integrator, Lead System Architect. Think about what Systems Engineering means to each of your teams, and see if working it into your teams improves you proactivity and helps keep your solutions "on track and in context".

[xitaqua]

Great article on systems engineering. You are dead on on many of your observations.

As a former President of INCOSE ( International Council of Systems Engineering) St. Louis Chapter I have to say that SE is a very complex discipline by itself and like psychology there are a lot different point of views and theories.

SE practitioners can spend many many hours discussing the finer points of a complex versus a complicated system, or a discussion about if there should be a BS degree in systems engineering.

There are still a lot work to be done to mature the discipline, and I recommend all the young SE to join your local INCOSE chapter and be active: http://www.incose.org/

To me one of the best examples of a System Engineer, is a 9-year old kid in East LA: http://cainesarcade.com/. He took a simple concept and ran with it. Today there are many young engineers replicating his process of developing arcade games.