Three events this week have me focused on the theme of simplicity. On Tuesday, I participated in a panel discussion hosted by the INCOSE Crossroads of America chapter in Indianapolis. We fielded multiple questions about the practice of Systems Engineering, including two that addressed how to simplify Systems Engineering for small companies and those with limited exposure to its holistic thinking methods. The common thread in our answers was the need to focus on the essential information required by the process, not the process itself.
On Thursday, I spent the day in Chicago at the International Manufacturing Technology Show (IMTS) viewing a dizzying array of new industrial technologies. I’m helping the research team at Connected Factory Global “boil the ocean” of Factory Automation (aka Industry 4.0 or IIOT) using our Decision Driven® Solutions Framework. Our goal is to produce a lean/mean pattern of factory automation needs, requirements, decisions and solution architectures that can help small/medium manufacturers take advantage of these new technologies. In essence, we’re trying to simplify, shortlist and inform the decisions they must make to stay competitive.
On Friday, I read David Long’s excellent post on Where to Leverage Simplicity (and Where Not To). David provided numerous ideas on how to simplify complex problems, while maintaining sufficient integrity/rigor of thinking to successfully resolve them. One statement stood out:
“If we are to truly understand the problem and craft a system solution, we must capture the full breadth and richness of problem and solution. This requires broad and rich concepts, both in the information we consider and the nuanced interrelationships.”
Time for some good news. The types of information/relationships required to understand any complex problem, bound the problem, decompose it into manageable set of decisions, make those decisions and successfully implement the solution chosen is known and stable, i.e. will never change. The remaining challenge is one of emphasis (e.g. the level/timing of effort applied to requirements, decisions, risks, etc.).
I’m clearly in the camp (hence the Decision Driven® brand) that believes that decisions are central and that a decision pattern creates a knowledge pull that highlights the essential information without lots of process overhead. There are still lots of information types and relationships to consider when designing a product/system, but if you get your top 10 decisions right, your chance of success skyrockets.
The enduring challenge that I see is that business leaders and engineers (in general) who could benefit most from Systems Engineering/Thinking are not trained as information architects. Showing them a lean-but-comprehensive information model that could help them simplify, focus and understand the essential knowledge they need (i.e. ask the right questions) will likely produce the opposite effect.
“That’s too complex/hard! It has to be simpler than that!
I’ll just draw up what I want in PowerPoint and run some numbers in Excel.”
We all want and buy multi-functional products that simplify our lives and work. But the thinking that creates such elegant and powerful solutions is necessarily complex.
What are your thoughts on how to overcome this challenge?