I’ve just been participating in a virtual seminar with Dassault Systèmes hosted by the Crystal Interactive JAM Platform when the unthinkable happened. I had just delivered a whistle-stop presentation on the subject of “Identifying the right MBSE Strategy” (MBSE = Model-Based Systems Engineering) when something went wrong and I lost my connection! I quickly rebooted, although I’m not on the critical path when it comes to rebooting, the OS is, only to discover it wasn’t me, or rather it wasn’t just me. Something had gone wrong in the internet-cloud-world-wide-web thingy.
Apologies for the disruption to the seminar if you were viewing.
The reason the seminar was virtual is that we have all needed to adapt to the COVID-19 situation. The obvious thing, therefore, seemed to be to pivot again. So I scooped up the questions from the chat (by scoop I mean ctrl-c) and decided to answer them here (ctrl-v). So in no particular order here are a selection.
I’ve attached a link to my slides below.
Q) How can you make a value proposition explicit and convincing?
A) If you want someone to buy something; a product, a service, or even an idea, then it has to satisfy a want. If you think your organisations would benefit from implementing MBSE, then you need to work out what the organisation wants? Is it less waste, quicker products, lower risk or something else? Focus on what the organisation wants and how MBSE will help it achieve that.
—-
Q) What is the biggest pitfall to avoid on an MBSE journey?
A) Not answering the “why?” question. All MBSE implementations are about doing better Systems Engineering. Start by establishing how your current Systems Engineering approach isn’t delivering what you need.
—-
Q) How to start an overall product architectural level with MBSE and then use different fidelity for different subsystem? Not to model all parts with the same detailed level?
A) You’ve practically answered the question yourself there! There are three ‘rules’ you can apply when decided when to stop modelling or how much details to include. Imagine you are modelling a subsystem and need to agree if you have done enough:
- Have a pre-defined gate at which point you will review the model. E.g. you may decide that the first gate will be when all the subsystems are modelled as black-boxes (no internal details), and you’re not going do any white-box (internal) modelling until the model is reviewed and agreed.
- Understand the purpose of the model. If an output from the model is going to feed into a downstream process, it must be sufficiently complete for that process. Understand what the downstream process requires.
- Assess the risk. If an element is of low risk (because it is of low complexity, mature or well understood) then include less detail than something which is high risk (because it is of high complexity, immature or not well understood).
—-
Q) Where does MBSE fit in the Digital Transformation of a company?
A) Digital Transformation is such a broad concept so this question is difficult to answer, but in general, MBSE is the ‘digital transformation’ of System Engineering (SE).
—-
Q) What are the best practices for the transition, regarding the legacy process’ and systems?
A) Understand them (preferably by modelling them!), understand their interfaces, improve them – some aspects will be good and worth keeping.
—-
Q) How do you bring supply chains along the journey?
A) In the same way that you convince management. Understand what they want and address that.
—-
Q) What is the right strategy in selecting the best suitable framework?
A) Define your needs, who are the model’s stakeholders, what information do they require from the model or what properties must the model have. Choose a framework which is the best fit for your needs and adapt as required.
—-
Q) How many times do you need to introduce MBSE into an organisation?
A) Hopefully only once, but nobody ever uses a big bang approach, so you usually need to introduce it to sections of the organisation incrementally. Each time tailoring your introduction and learning from previous experience.
—-
Q) How many iterations of model frameworks do you think it takes to get the right model framework?
A) Generally, you wouldn’t try and completely define your framework in one go, so each iteration may modify existing elements and add new ones. Your framework needs to evolve as your business evolves so probably the truthful answer is you never get it right. The key metric is how far behind the change is it?
—-
Q) Are your customers typically starting from top or bottom?
A) Usually, the middle. Individuals sometimes start to model, but it’s not MBSE until it’s a collaborative endeavour, so it needs to be happening in teams and across teams. Upper management may decide MBSE is a strategic goal, but all the work happens in the middle.
—-
Q) What guidance would you suggest for implementing MBSE where you are trying to draw out stakeholder needs rather than being given a set of stakeholder needs?
A) Focus on the problem domain, explain how well the stakeholder needs you have been given address the issues and here’s my personal favourite; when somebody says “we need x” ask “what would need to change for you not to need x?”
—-
Q) Is functional safety a reason to start with MBSE, e.g. new automotive ISO standard to follow.
A) Yes – the administrative burden of creating a safety case means you need smarter ways to store your Systems Engineering data. MBSE is a smarter way than Microsoft excel (other spreadsheets are available and also not recommended).
—-
Q) What is the best-selling argument for MBSE to top management?
A) James said it was a good idea! But seriously, examine your companies goals, analyse your engineering weaknesses (are you slower than you would like or do you make too many errors etc.) and look at what your competitors are doing. But remember – faster product development does not mean faster Systems Engineering, it means better Systems Engineering (which may be more effort) and less testing and rework.
