“There is nothing as useless as doing efficiently that which should not be done at all.”
From prior reading in the blog series, you know what systems engineering is and how it needs to be supported by model-based system engineering (MBSE) models to handle our product complexity. However, implementing MBSE in your organization is yet another level of systems engineering, i.e., we are implementing MBSE inside yet another complex organizational system that is, in itself, living inside a complex product market. As such, we shouldn’t expect to step into our existing paper-based practices and get the productivity improvements we seek without making some organization and process changes. Yet that happens in many organizations, leading to MBSE failures in organizations that attempt to automate existing practices without considering whether those practices should be automated.
I grew up in a large family. Sitting around the dinner table talking at one family get-together, my sister asked my mother, “Why do we have liver and onions every Thursday night for dinner?” My mother responded, “Your father loves liver and onions.” My father replied, “I don’t like liver and onions. I only eat it because you love liver and onions.” Mom, already nodding her head, didn’t like it either, and thus it went around the table, discovering that no one in the family liked liver and onions, yet we had it for dinner every Thursday night.
Systems engineers are always asking the “why” question. Systems engineering is about considering the many different aspects that impact the product and considering/trading off those aspects to achieve a product balance (a product that does what it’s supposed to do, in a cost-effective way, that is safe, reliable, that works in its intended environment, and the list goes on). Product development organizations are complex systems, too. If you attempt to implement MBSE without considering that, you shouldn’t be surprised you have built islands of automation that can’t communicate with each other, perpetuating the communication problem you hired the tools to solve. This means that implementing MBSE isn’t a tool but a journey.
As with any journey, you need to know where you are before you make your travel plans. This is why we developed a practice of mapping organizational MBSE maturity by understanding what technologies you are currently using to do systems engineering (i.e., a simple way to find out where we are). Once we know where we are, we can plan a journey that can change your organization with a successful MBSE implementation.
So where are we…
We find out where you are by asking what technologies you are currently using to do the systems engineering job:
The first column of this matrix summarizes what systems engineers are supposed to do based on standards (like ISO15288, IEEE 1220). For example, systems engineers define the requirements, develop the product architecture, define the constraints, i.e., parameters to be used, understand the impact of change, etc. You could do those systems engineering jobs using various tools, technologies, and practices based on paper and models.
For example, looking at the requirements management row from left to right, you could manage requirements using uncontrolled spreadsheets and documents, controlled documents in a shared document repository, or you could manage requirements in stand-alone requirements tools (there are many out there). As you move to the right across this row, you’re moving from disconnected practices on the left to integrated practices on the right (remember, we are after continuous integration), so as we move to the right, requirements begin to show up in places like inside CAD models or math models. The most integrated practice on the right is “requirements are part of the product baseline,” so they are controlled like the rest of the product structures, tied to other things inside the product like parts, tasks, test procedures, change management, etc., enabling complete traceability to where a requirement goes when it changes.
To pick another example row, we manage interfaces because they represent the agreements between the silos (I’m going to deliver this content that looks like this, at this time) that allow everyone to develop an integratable product. If we fail to deliver what we agreed when we agreed to deliver it, we end up with an integration problem. This is why all the bad things in a product’s life happen at its interfaces and why they are so critical (…and why my college professors said systems engineering is all about managing interfaces). Today, almost everyone uses interface control documents (ICDs) to manage interfaces on the left. At the same time, the advanced practice on the right involves defining interfaces by allocating functions (i.e., assigning functions to things that accomplish that function defines an interface; for example, allocating the “stop vehicle” function to things that perform that action defines an interface between everything involved in stopping the vehicle). If interfaces are included in the product baseline (level 5 thinking in the above matrix), they will carry interface knowledge throughout the product, allowing you to see where a function is performed and where a function change goes (for example, imagine walking up to a wire or hydraulic line and asking it what functions cross here).
Suppose you’re down at level 1 managing interface in a document with no functional allocation (or functions defined at all). In that case, jumping to level 5 capabilities is impossible, but we could start from where you are by taking a step to the right. For example, you could import your ICD into Teamcenter and start managing individual interfaces as part of change, workflow, history, etc. That step is of incredible value and sets us up for the subsequent improvement of reusable interface libraries to enable reuse, etc. and so our journey begins.
This incremental MBSE journey, with little victories like interface capture, requirements impact understanding, trustworthy parameters used across an enterprise, and focused testing vs. testing everything when anything changes. This will provide little bright spots that everyone in your organization can see, helping motivate the organization through the change needed to achieve the full value and capabilities of MBSE.
So, how/where do you start your MBSE journey in your organization?
We’ve done enough of these assessments in various organizations and industries, and we have 95.6% confidence that you are an average organization (see above matrix). Starting at the bottom of the matrix, we can predict that you are using your PLM system to manage CAD models, that your test cases are managed outside of PLM, the various behavior models (math, behavior, Excel, etc.) are kept either on individual’s desktop or in GIT. We assume requirements are managed in standalone management tools outside PLM, you are still using document based change practices, with many parameter repositories around your organization, with some functional architectures kept in documents, you use ICD’s to manage interfaces, technical risk in risk documents and spreadsheets, product-line variation descriptions in documents, and product architectures kept in Visio with some SysML modeling on some projects.
Tell me I’m wrong.
So we suck– what do we do about it? Given where you are and based on our experience, we recommend starting with areas you’ve already invested in over the years and focusing on getting value out of that existing investment: requirements, parameters, test, and change management. Start with your existing requirement repositories, do the meta-data mapping, and co-exist with them in your Teamcenter repository. Once there, you can link them to things like parts, tasks in program schedules, manufacturing processes, etc. This will give you the requirement change impact. You need to understand where things go now versus later. With the requirements in place, let’s get the test cases imported and linked up with the requirements. After all, tests are there to validate requirements. This allows you to do focused testing (testing only what is impacted by the change vs. testing everything, every time, since you don’t know where a change goes). You’ll want to get your parameters under control next since they are used in conjunction with the requirements. Imagine the value of a trustworthy enterprise parameter library (vs. hundreds of parameter repositories spread around your organization) that can be referenced in requirements, simulation models, etc., to minimize wasted time and money on the wrong versions of parameters used across the organization.
These little victories will produce measurable improvements and prove that integrated MBSE is worth the journey. Those bright spots will help change your company culture needed to make MBSE stick by providing continuous feedback on where “straight ahead is” (see earlier blog on walking in circles).
Nature is ahead of us…
It turns out this is how nature gets everything to align…
You’ve probably been hearing about the current Cicada-geddon happening in various regions in the U.S. I grew up in Las Vegas with Cicadas almost every summer with their deafening buzzing. I didn’t think of it then, but all their buzzing noises were synchronized. Just like crickets chirping is synchronized, fireflies flash synchronized, and other things like your brain waves, heart rhythms, and more (just like we’re trying to get our organization’s development practices synchronized continuously). It turns out someone noticed this behavior in fireflies and wanted to know how they chose a leader to start syncing with (suggest you read up on the science of synchronization or a TED talk on the topic). It turns out that fireflies don’t choose a leader; their flashing clock gets nudged in small increments every time another nearby firefly flashes, eventually leading to all fireflies (and crickets and cicadas, brainwaves,….) triggering at the same time. I suggest you try out this firefly simulator to see how fireflies synchronize with each other even with disruption. That’s interesting, but imagine controlling it. Check out controlling firefly firing with programmable LEDs.
Remember, our goal is to synchronize whole organizations so we can be continuously integrated (start integrated, stay integrated); imagine applying this technique to small victories to MBSE implementation. Organizational change comes with small incremental changes. These are little steps on your integrated MBSE journey; they will create bright spots that will nudge others around you to synchronize with you and, over time, synchronize the entire organization. Teamcenter solutions support this, and we can help you along this journey– just let us know.
In Summary…
So, how do we move from disconnected silos where we are to this integrated SysLM?
Here’s how the practice works…
- Find out where you are in your MBSE maturity
- Pick out some short-term value projects to implement
- Attract attention with your small victory
- Repeat
…we will pick up back up on taking the following steps with a discussion on justification and some case studies over the following months. Please join us for the conversation.
Mark Sampson
Systems Engineering Evangelist.