/>
Back
Product Lifecycle Management Services
Avoid disruptions and increase revenue with Product Lifecycle Management services.
Learn more
Capabilities
Applied CAx Teamcenter Tools
Our proprietary Teamcenter tools help administrators optimize PLM, migrate data and easily integrate solutions.
Learn more
Explore Teamcenter Tools
Back
Software
Achieve a sustainable competitive advantage with software licenses, training and technical support from Applied CAx.
Learn more
Product Lifecycle Management
Mechanical Design
Manufacturing
Simulation & Test
Back
Applied CAx Trainings
Whether you’re looking for Teamcenter, Simcenter FEMAP & Nastran, Simcenter 3D, NX CAD or NX CAM, Applied CAx has customizable training options for any company to get up to speed faster.
Learn more
Training Courses
Upcoming Trainings
Back
Resource Center
Explore our curated library of resources, thoughtfully crafted by our experts to polish your skills and expand your knowledge—and maximize your investment in Siemens Digital Industries Software.
Learn more
Simulation
Product Lifecycle Management
Manufacturing and Design
News
Case Studies
Applied Imperative Podcast
Featured Resources
Back
Get Support
Back
Aerospace & Defense
Applied CAx helps aerospace and defense companies strategize, implement and execute digitalization strategy.
Learn more
Energy
Applied CAx assists energy companies in accelerating adoption of new tools that streamline engineering processes.
Learn more
Back
Our Company
Since 2008, Applied CAx has partnered with innovative companies to maximize the value of their digital tools.
Learn more
Blog
Explore Siemens news and updates from Applied CAx.
Learn more
Featured News
Back
Get started
Get started

Take our MBSE maturity assessment and get a real-time maturity score

Use the toggles to indicate your model-based systems engineering maturity score. Move them from left to right, placing them under the level that best fits your current state. The column to the left describes things that system engineers do, while the column on the right with the toggle selections describes how systems engineers do these things.
Average MBSE maturity (all industries)
  • 1 - Initial Uncontrolled
  • 2 - Managed Controlled documents
  • 3 - Defined Isolated models
  • 4 - Qualitative Enterprise integration
  • 5 - Optimizing Continuous engineering
Content management
Physical design
management
CAD, CAE control/mgmt
Where do you manage CAD, CAx models?
  • Unmanaged storage, desktops (etc.)
  • PDM system
    Enterprise whole model repository
  • SE artifacts linked into
    CAD
    Model repository with links to requirements/parameters
  • SE artifacts linked
    across domain
    Fine grained enterprise model repository with situational awareness, i.e. hole is aware what wires/pipes pass through it
  • Continuous physical design verification (digital twin)
    Virtual matches reality
Verification management & governance
Test proves the product does the right thing
Product test/V&V
Where is test managed?
  • Uncontrolled document-based test procedures
  • Managed test
    cases
    Disconnected test cases/management with no traceability requires testing everything every time
  • SE artifacts linked into
    test
    Test integrated & configured- tied to requirements, etc.
  • DevOps-like V&V HIL/SIL
    simulation
    Automated test execution with mixed models included in runs
  • Continuous focused
    testing
    Testing only things affected by change with continuous feedback to design
Behavior model
management
Behavior models of all kinds help you make design decisions
System, performance, et al. simulation
Where do you manage behavioral models?
  • No control, uncontrolled models on desktops
  • GIT-like version controlled model repository
    GIT-like version controlled models
  • SE artifacts linked into models
    Requirements/parameters linked to behavior models
  • PLM model & product config with simulation
    Model elements included in product configuration includes multi-domain/multi-attribute simulation
  • Continuous simulation & multi-domain optimizing
    Focused simulations: simulating only what has changed with ripple effect
Requirement analysis
Requirements describe how well a product does something
Requirements engineering & mgmt
Where are requirements managed?
  • Uncontrolled
    spreadsheets & docs
  • Managed requirements docs (sharepoint, etc.)
  • Standalone RM tools
    with exchange
  • Integrated w/ other domain models (CAD, etc.)
    Individual requirements included in PLM services (change, workflow, configurations)
  • PLM-enabled continuous compliance 
    Cross-domain traceability enables continuously "compliant by design" products
Integrated services
Change management
Change happens
Where do you manage change?
  • Document-based
    change process
  • PDM change practice including some models  
  • PLM with change impact
    & suspicion mgmt 
    Change includes suspicion impact notification & clearance managment
  • Inside PLM with models, params, history
    Product configuration includes model related elements (parameters, models, etc.)
  • PLM change history is next starting point 
    Complete BOM, models, history, lessons, etc. available for next program
Parameter/target mgmt
Parameters are used across products & domains such as 12v, speed, & size. Targets are allocatable goals the product will meet like weight & cost.
Characteristic/targets/TPM
Where are parameters/targets managed? 
  • Many uncontrolled 
    spreadsheets & docs 
  • Controlled spreadsheets & docs inside a project
  • Project/division-based parameter/target
    Project-level repositories with classic management practices & tracking
  • Enterprise PLM parameter/target mgmt 
    Parameter/target included in configuration with traceability to their use
  • PLM params & targets for continuous compliance
    Parameters & targets tied to test, warrantee, etc. with continuous monitoring. Target watchdogs sound off via dashboard.
Feature engineering
Functions describe ‘what’ product does such as “stop vehicle." A Feature is a gathering of functions to deliver capability.
Feature/functional modeling
Where are features/functions managed?
  • Feature/function
description docs
  • PLM-based functional hierarchy
  • Behavior models tied to controlled functions
    Behavior modeling outside PLM
  • PLM func modeling using standard params/reqs
    Functional breakdown tied to requirements, logical & physical breakdowns
  • PLM func arch allocations for func visibility
    Functional allocation decisions drive interfaces which flow throughout product i.e. wires know what functions they carry
Cross-domain services
Systems definition & design integration
Interfaces are agreements between communicating product elements
Logical modeling & interface mgmt
Where are interfaces & logical architectures managed? 
  • ICD & logical
    description documents
  • PLM managed interfaces
    & logical hierarchy
    Individual managed interfaces & logical breakdowns
  • Interface libraries tied to SE artifacts
    Requirements/parameters linked to logical models & interfaces
  • Interfaces using PLM managed params/reqs
    Configured logical & interface elements included in PLM services
  • PLM arch across domains for continuous I/F mgmt 
    Interface definitions carry across domain to enable cross-domain communication for continuous integration (i.e. wires & pipes know what functions they carry)
Product engineering
Reliability & system safety analysis
Product reliability, availability, maintainability & safety
Technical risk (RAMS)
Where is technical risk managed?
  • Risk documents
    & spreadsheets
  • Risk mgmt plans with manual RAMS artifacts
    Risk management plans/artifacts inside program risk management process/practices
  • Disconnected RAMS tools output artifacts
    Siloed risk assessment tools used to generate risk analysis artifacts
  • PLM-integrated RAMS analysis tied into arch
    Risk analysis gathers & updates assessment parameters inside PLM
  • Continuous RAMS risk assessment & alarms
    Change, gates, etc. - triggers continuous risk assessments with suspicion management
Planned product variability
Considering product line & variation in product decisions
PLE/configuration/variation
Where is product variation managed?
  • None
  • Variation documents & spreadsheets
  • Through disconnected variation rules
    Variation described/managed outside PLM applied as post-process
  • Integrated PLM variation rules managed & applied
    Product variation/configuration managed inside PLM
  • PLM variation drive  architecture decisions 
    Product architecture decisions influenced by integrated product line/variation considerations
System architecture modeling
Product architecture are the blueprints for entire product development effort
Product architecture definition
Where is the product architecture kept/managed?
  • PPT docs
  • Visio diagrams (managed in GIT, etc.)
    GIT-like version controlled system diagrams
  • Standard SysML modeling tools
    Standard system models & methods outside PLM
  • Integrated system architecture inside PLM 
    Architecture elements inside PLM tied to requirements/logical and physical breakdowns
  • Continuous integration via PLM architecture
    Integrated architecture drives downstream dev (CAD, EDA, EE, Mfg) including suppliers (model based design chains) enabling continuous integration
Generate your MBSE maturity score
Submit your information and you will receive your score and an overview of your company’s MBSE maturity. We will email you a more in-depth report so you can share with your team. Our MBSE experts are always on hand to help you improve your score. Hand the details over to us so you can focus on what you love to do - innovate!
Your MBSE maturity score.
Level 1 (score 0–11)
Level 2 (score 12–20)
Level 3 (score 21–30)
Level 4 (score 31–40)
Level 5 (score 41–55)
Level 1 (score 0–11)

Relies on a traditional, document-based approach (physical or digital paper).

  • Characteristics: Information is scattered across documents, spreadsheets, and models. It is often uncontrolled, making it difficult to verify the latest versions, resulting in significant time wasted searching for information and missed product problems.
  • Symptoms: Searching for the right information is time-consuming and unreliable. This leaves you missing your window of opportunity, crossing your fingers and hoping for the best.

 

Want to understand the reasons why MBSE is so important? Watch this short video on the integrated MBSE vision.

Level 2 (score 12–20)

A document-based approach with controlled repositories (e.g., SharePoint, PLM systems, etc.).

  • Characteristics: While the latest documents are available, users still spend considerable time searching for specific information. Text-matching tools may identify relationships between documents but fail to provide insight into the models or underlying context.
  • Symptoms: Because text doesn’t scale, information often lacks context, leaving you uncertain about its accuracy and again resorting to hoping you’ve verified everything.

Want to understand the reasons why MBSE is so important? Watch this short video on the integrated MBSE vision.

Level 3 (score 21–30)

Shifts from documents to granular components, such as individual requirements, test cases, and various version-controlled models (e.g., mathematical, behavioral, performance).

  • Characteristics: Controlled components begin to exchange information, enabling traceability between models. However, this data remains disconnected from overall program baselines/configurations, offering limited context.
  • Symptoms/Benefits: While controlled requirements and test cases are valuable, the lack of whole-product context and situational awareness leads to recurring problems and inefficiencies, resulting in optimizing in silos vs. optimizing the whole.

 

Want to understand the reasons why MBSE is so important? Watch this short video on the integrated MBSE vision.

Level 4 (score 31–40)

Integrates fine-grained product information with program configurations/baselines.

  • Characteristics: Facilitates navigation of relationships and a deeper understanding of how changes impact the broader program. Cross-domain situational awareness develops (e.g., tracking how a requirement change propagates now vs. finding issues later).
  • Symptoms/Benefits: Enhanced situational awareness based on current product configurations allows for better impact analysis. Cross-silo optimization enables focused work, such as retesting only what has changed rather than testing everything.

 

Want to understand the reasons why MBSE is so important? Watch this short video on the integrated MBSE vision.

Level 5 (score 41–55)

Builds on Level 4 by automating integration across domains.

  • Characteristics: Enables continuous, DevOps-like integration for cross-organizational optimization. For example, a change in a requirement automatically identifies affected assets, schedules necessary verifications, and allocates resources efficiently.
  • Symptoms/Benefits: Continuous integration, proactive problem identification, and program-level reuse will empower you to outpace competitors through faster, more efficient operations.

 

Want to understand the reasons why MBSE is so important? Watch this short video on the integrated MBSE vision.

One of our MBSE experts will be in touch with you shortly to determine your best strategy for improvement. In the meantime, a more in-depth report will be sent to your email so you can dive deeper into your score and share it with colleagues.
Retake Assessment Contact Us
Percentage: 0%
Average MBSE maturity (all industries)
This scale helps you rank your systems engineering processes using the assessment questions. You will use this scale to identify the level that most accurately reflects your current systems engineering practices.
1 - Initial Uncontrolled
This level represents minimal control and significant opportunities for improvement.
2 - Managed Controlled documents
Processes rely on structured documentation, but integration between systems remains limited.
3 - Defined Isolated models
Utilize formalized models for specific tasks, though collaboration and system-wide integration are minimal.
4 - Qualitative Enterprise integration
Models and processes are integrated across teams, supporting enterprise-wide collaboration and qualitative decision-making.
5 - Optimizing Continuous engineering
Processes are fully optimized, leveraging continuous feedback and improvement across all stages of the lifecycle.
Begin Assessment
Content management
Select the radio buttons on the right of each item to choose the level of maturity you believe your organization is at. The questions in white before the options in color are things systems engineers do, while the options in color are how systems engineers do these things.
Question 1
Physical design
management
Where do you manage CAD, CAx models?
Question 2
Verification management & governance
Test proves the product does the right thing
Where is test managed?
Question 3
Behavior model
management
Behavior models of all kinds help you make design decisions
Where do you manage behavioral models?
Question 4
Requirement analysis
Requirements describe how well a product does something
Where are requirements managed?
Next Section
Integrated services
Select the radio buttons on the right of each item to choose the level of maturity you believe your organization is at. The questions in white before the options in color are things systems engineers do, while the options in color are how systems engineers do these things.
Question 1
Change management
Change happens
Where do you manage change?
Question 2
Parameter/target mgmt
Parameters are used across products & domains such as 12v, speed, & size. Targets are allocatable goals the product will meet like weight & cost.
Where are parameters/targets managed? 
Question 3
Feature engineering
Functions describe ‘what’ product does such as “stop vehicle." A Feature is a gathering of functions to deliver capability.
Where are features/functions managed?
Next Section
Cross-domain services
Select the radio buttons on the right of each item to choose the level of maturity you believe your organization is at. The questions in white before the options in color are things systems engineers do, while the options in color are how systems engineers do these things.
Question 1
Systems definition & design integration
Interfaces are agreements between communicating product elements
Where are interfaces & logical architectures managed? 
Next Section
Product engineering
Select the radio buttons on the right of each item to choose the level of maturity you believe your organization is at. The questions in white before the options in color are things systems engineers do, while the options in color are how systems engineers do these things.
Question 1
Reliability & system safety analysis
Product reliability, availability, maintainability & safety
Where is technical risk managed?
Question 2
Planned product variability
Considering product line & variation in product decisions
Where is product variation managed?
Question 3
System architecture modeling
Product architecture are the blueprints for entire product development effort
Where is the product architecture kept/managed?
Next Section

Learn more about model-based systems engineering

Explore all of our MBSE resources and learn how to accelerate your journey. Crafted by our MBSE Evangelist, Mark Sampson, these resources will help you start integrated and stay integrated.

Explore all MBSE resources