Many experts boastfully claim that organizations must adopt all system engineering practices to reap any benefits. This post challenges that stance.
All of it. You need all of it.
That’s the message that seems to float around system engineering practices and principles. You see, while I attended a number of conferences over the course of the last year, I’ve asked the same question again and again “can you adopt system engineering piecemeal?” I’ve been met with that answer, you need all of it, again and again.
That’s is the part where I get uneasy. Why? Let me explain.
Lessons from the Past: PLM
Having a big vision is a good thing. As an industry, I think it is a good thing when audacious goals are promoted. It helps manufacturers visualize what can happen when they adopt the right set of processes, roles and responsibilities as well as technology. Such visions are good in helping manufacturers realize they can do more. These are tools you can use to pursue opportunities or mitigate threats in their business.
Now while that is a good thing, there are two caveats to take into account.
- Be careful pursuing the adoption a big monolithic initiative. Having a big vision is great, but you should employ that vision piecemeal instead of a large scale deployment. Build it step by step, gaining success and learning lessons along the way. Manage the change, from a process, cultural and technological perspective. It took almost a decade before this kind of advice was used in adopting PLM. It was tough going for those early adopters.
- Beware of dogmatic sequential adoption plans. With PLM, a scripted path was promoted. First, get your MCAD data management in place. Second, get your engineering release and change management under control. From there, you can go after anything you want in the company. The problem here lies in the fact that there may be a huge burning issue that needs to be solved now. And that problem might have nothing to do with data management, engineering release or change management.
No joking, I know numerous companies that went full bore with PLM, starting down the path of global data management. Their vision was to manage the product through the entire lifecycle, end-to-end. Many of those companies, some ten years and tens of millions of dollars later, are still stuck in deploying data management. They never got to realize their bigger vision, to chase those bigger fires that were critical to the company. Our recent studies show that few are dedicated to enterprise systems for that first step, data management.
In the last few years, PLM has been changing. It has become much more granular, allowing companies to adopt a small piece of functionality. It has also become much more flexible. If a company has a burning issue, they can skip data management and change management. They can come back to it later or completely ignore it.
What’s the takeaway? Modern solutions for any development issue need to be granular for easy deployment and wins. They also need to avoid scripted adopted sequences that require one step ahead of others.
How System Engineering Can Benefit
Now, systems engineering has a LOT of value to offer manufacturers. Even though some products have plateaued from a mechanical hardware perspective, almost every product has more software, electronics and connectivity in it than ever before. System engineering can help manage that increasing complexity. I suspect that it could help even smaller and mid-sized companies in specific areas. However, that doesn’t mean that manufacturers need to repeat the errors of PLM.
Now, let’s look at some different areas where system engineering can make a difference.
- Architecture Breakdown: This is known by a lot of different names, but the idea here is to take progressive steps to determine your system architecture. It starts with customer requirements> You can then define functions that will fulfill those requirements. After that, you start developing your architecture with hardware, electronics, on-product software and off-product IT capabilities for IoT enablement. There is a ton of value here for companies that need to get more disciplined in determining how their product technologies should fulfill customer needs.
- Requirements Breakdown: An organizational capability that can be used in parallel with Architecture Breakdown is assessing and breaking customer requirements into more minute granular requirements. Each breakdown creates a relationship from parent-to-child for traceability as well.
- Systems Modeling and Simulation: This concept allows engineers to develop their system in a diagram-like model where items performance is calculated with formulas and equations. The purpose is to assess performance and run trade studies to improve the design. This is a great approach to validate that the architecture that has been developed will, in fact, work together in an integrated fashion and meet expected performance.
- Interface Management: Wherever two disciplines, or even two teams within a discipline, have abutting designs there is an interface. Defining and managing that interface is a way to manage and coordinate change between teams. Doing this in a rigorous way means the likelihood of running into integration issues downstream is reduced.
- Modularity Management: While not explicitly known as a part of system engineering, this level of organizational capability works with it. This capability allows organizations to create equivalent sub-systems or assemblies that can be interchanged. But using this approach allows the company to explicitly plan out those different modules such that it has an effect at the product level, thereby offering more product variations.
Discretizing System Engineering
Are these different areas interrelated? Absolutely.
Do you need to implement all of these capabilities together? No.
Can you implement one of these capabilities and get value? Absolutely.
Here is my overall point. If a company can, say, adopt architecture breakdown, get to better system architectures and improve their product, why not do that… and just that? The organization gets value. The organization isn’t overwhelmed by the immensity of systems engineering. They can certainly return to other facets of system engineering when the time is right. In my mind, this tenet holds true of each of these capabilities. Each can be adopted on their own without the others.
If you’re an advocate for system engineering, I know you love it. I know you see value in all of this working together. But for some companies, that just might not be feasible. But furthermore, those companies need to get value fast. They need a win. They can do that by adopting something small and contained.
That’s my take folks. If you have something to add, sound off in the comments section.
Take care. Talk soon.