Interview with Clotilde Marchal, Vice President “Process Methods and Tools” at Airbus Group, on the significance of Systems Engineering for product development.

SE is deemed to be a powerful tool for complex product development. However, its implementation is often linked to various challenges. Dr. Stefan Wenzel in dialogue with Clotilde Marchal, Vice President “Process Methods and Tools” at Airbus Group, about the relevance of SE in an enterprise with a complex product development process (PDP), the challenges of the SE introduction, and about why community is the crucial success factor for its implementation. In May 2011, Clotilde Marchal started her job at Airbus Group where she chairs the corporate Systems Engineering Steering Group (SESG), which coordinates all Airbus Group divisions activities in SE. She has previously worked for 20 years in Software Engineering before finding her way to the Systems Engineering world

Mrs. Marchal, Airbus Group is a pioneer in Systems Engineering. What relevance does Systems Engineering have for Airbus Group today?
Systems Engineering is an important topic. It has been identified as one of the twenty-two core competences of the company. From all disciplines and from top management, we see Systems Engineering as very important to have. This is linked to the fact that we are working with very complex products and systems.

In your opinion, what is the biggest benefit in the introduction and implementation of Systems Engineering?
I think the best benefit is the quality of the product which is definitely improving through SE. Additionally, SE helps us to improve mastering the planning along the V-Model. When we define the requirements, we already think about the validation of the requirements.
A third benefit is that through Systems Engineering the chief engineer is today getting more importance and his job is highly acknowledged within the organization.

Are there any benefits for the customer despite quality?
With the help of SE, we can also increase customer satisfaction which is directly linked to the quality of our products. But I think there is another benefit that is important for us: through Systems Engineering, the relationship with the suppliers is improved. We have a lot of suppliers, and with Systems Engineering we can better define the interfaces and focus on them. We know that interfaces are always the devil because they are really tricky to handle.

In your point of view, how does Systems Engineering differentiate from “standard” product development?
I don’t see a standard product development without Systems Engineering anyway. I think it is mandatory and really has to start from the beginning. What are the customer’s needs? Who are the stakeholders? How are you going to verify what you want to do? If you don’t ask these questions you can’t call it normal product development.

Looking back now on this long-standing experience with the implementation of Systems Engineering within the whole company, and from your standpoint, what are the crucial success factors for the implementation or the improvement of such a discipline?
One of the first crucial success factors is to have a community which is gathering people, regardless of whatever the organization is and whatever the organization will be like. This is important because organizations are changing every two years, and the people are still there. People should have a way, an area, where they can still network, exchange ideas, work together, think about the best way of Systems Engineering, whatever happens in the company.
The main challenge for creating this community is that systems engineers are typically hidden. There are, of course, some departments which are called “Systems Engineering”. But many departments or job roles cannot be related that easily to this discipline. They are called architect or software engineers or anything else, but behind that they are all systems engineers. So, in my case, I first identified the right people through the SE trainings they attended; then little by little people connected to this community and we have now more than 1200 members. This way we can maintain the effort, we can maintain the sharing and we can continuously improve.

The main challenge for creating this community is that systems engineers are typically hidden. […] They are called architect or software engineers or anything else, but behind that they are all systems engineers. 

The second success factor is that Systems Engineering is recognized and trained at different levels. In any product development of any of our companies, there are now Systems Engineering processes and we have also developed Systems Engineering training at group level and in the different divisions.
There is a learning path on Systems Engineering and there is also a development path which is important. This is in particular a success factor because in the past you were only promoted because you were a Senior Manager or a Senior Expert and now you can be promoted as a Senior Systems Engineer on one of these career paths.

It is really interesting that the first thing you mentioned is the building of a community and not the implementation of processes or structures which are important for Systems Engineering …
This is because the processes have always happened and will always happen here at Airbus Group without problems. But creating a community in 2012 when I started my job, that was really new. Now, we have a hub with four thousand communities. This fact shows that today there is a need to connect. If you don’t have a community of people you cannot disseminate. And dissemination is crucial to get Systems Engineering considered in projects.

If you don’t have a community of people you cannot disseminate. And dissemination is crucial to get Systems Engineering considered in projects. 

What have been the biggest challenges during the introduction of SE?
The biggest challenge was having and using a common vocabulary. We needed to be sure that we were sharing the same concepts at Airbus Group level.
Another challenge was to be able to share the processes across the different divisions. It is easy to share methods, but the processes are sometimes very linked to the specific products of the divisions. Furthermore, it was also hard to define a common development and career path. It took a lot of time to agree that we will not have a third career path for SE next to “management” and “expertise”. Instead we now have an additional SE development path which can be customized to the expert or to the management career path.
Finally, it was also a challenge to make people aware of the added value of Systems Engineering, because it is not always easy

In your point of view, did the classic Systems Engineering change within the last ten or twenty years? And is it still evolving?
Yes, there has been a change. You can see it in the different notions which are evolving. There is the modelling aspect as implied in Model Based Systems Engineering (MBSE). Additionally, there is also the ‘Agile World’ leading to Agile in Systems Engineering.
Each time there is a new concept in engineering, people try to apply it to Systems Engineering as well, which is good in a way as it means that Systems Engineering is mandatory. So, modern Systems Engineering is going on and improving in these areas. But for ‘Agile’ I would be more cautious. ‘Agile’ is embracing so many things, not only engineering. Even the original softwarerelated ‘Agile’ is not yet completely implemented well, and therefore we should still consider carefully before simply saying “I will apply it to Systems Engineering.” to explicitly assign the success of a project to SE.

Generally speaking, I think today we are more talking about model-centric projects where we still apply Systems Engineering. However, the model and the data are the core of our project rather than the documents and requirements, for instance. So we can definitely say that the classical requirements and the classical V-Model have been evolving and still continue to do so.

Do you measure the benefit of Systems Engineering?
Yes, we are working on that. It is not easy. We have a project at Airbus Group level to better share the practices of every project.

Do you mean it is difficult to measure the benefit of SE because it is still emerging?
Yes, SE is still emerging. It is a young discipline anyway. It has only been thirty, forty years, which is not much compared to other disciplines. So, we are still in this period where a young discipline hasn’t got everything and nobody can claim today to have a real obvious KPI for Systems Engineering. We still have KPIs in the sense that we compare. We compare the evolution of our project, the quality, the customer satisfaction, the cost whether it is increasing or decreasing.

How is Systems Engineering positioned in your company’s organization?
I think SE does not really have a significant impact on the organization itself. It is positioned more like a core discipline but there is not a global center of competence on Systems Engineering in the company.

But within the projects you established different SE roles?
Yes. The chief engineer role is identified and the Systems Engineering team with the architect is identified. The role of chief engineers and systems engineers in projects is now really seen as core.

From your point of view, what kind of competence and skills do good systems engineers need?
There are a lot. I think the one which is the trickiest one, and the one that sometimes people don’t have and can’t be trained with, is the “systems thinking”. The systems thinking is for us one of the qualities you must have. Being able to embrace the big picture. That is why we sometimes make a difference between the skills and the competence because the skills can be trained, competence however, cannot. Competence comes with the experience you gain on the job and if you are not up to this you will never get it. For me, systems thinking is something you can train only very little. I mean, it is really something you have or you don’t have. People who are too analytical will never get the big picture. To do Systems Engineering you also need a sense for the abstraction level. You can never find an architecture or be able to imagine something completely virtual if you do not have the ability to see it on an abstract level.

I think one of the main weaknesses […] is that we cannot yet really measure the benefit of Systems Engineering. For me this is the key weakness of this discipline because SE is really powerful but it cannot show its power by a simple computation.

What are the weaknesses of Systems Engineering today?
I would say the weakness of the systems engineer today is to be still too young. Also, there are still many things to develop and to settle. Furthermore, I think one of the main weaknesses linked to your question of the KPI is that we cannot yet really measure the benefit of Systems Engineering. For me this is the key weakness of this discipline because SE is really powerful but it cannot show its power by a simple computation.

Digitalization and IoT are currently on everybody’s mind and trends for the future. What does that mean for Systems Engineering? What impacts do you expect?
I expect that, especially for Model Based Systems Engineering, it will be really helpful. Digitalization will support MBSE a lot. In my opinion it will also help to better connect the people in the engineering teams, to further facilitate dissemination of the big picture of Systems Engineering.

So, digitalization is an enabler for Systems Engineering?
Yes. I think so.

Is Systems Engineering an appropriate approach to cope with digitalization?
With the MBSE yes. We are evolving more and more to MBSE. It seems really mandatory now. The classical Systems Engineering applied without modeling, I think, will die. I’m quite sure that there will be only modelling in the future. At Airbus Group level we already have a huge campaign and a huge deployment of MBSE today.

What does MBSE exactly mean for you?
Well, it means something important for me. It means that you really work around the model. The pitfall or the trap is to think that you are going to do MBSE and not SE anymore. In fact, you are always practicing SE, and MBSE is just a promising enabler. If we can share a model across a project and across the disciplines on the long life-cycle, this is really, really powerful because it optimizes the cost of managing interfaces between the domains and across the life-cycle. Here, MBSE can help to handle all these huge and painful tasks in terms of traceability of the document levels. Nevertheless, MBSE is a good enabler for Systems Engineering but do not forget to apply Systems Engineering anyway!

I hope that people will soon understand the power and value of Systems Engineering.

Do you see any future trends in the next ten years despite these things we talked about?
At the moment, SE is mainly established in Aerospace and Defense and I think that in the civil and especially health care sectors it will grow. I have a feeling that Systems Engineering will be, sooner or later, mandatory everywhere, in every domain. The trend is to cover other business domains. I hope that people will soon understand the power and value of Systems Engineering.

Which advice do you want to give to companies which are just starting to introduce Systems Engineering?
If they are starting, I would say recruit the right people. Some key people at least.
Secondly, they should rely on the INCOSE chapters because that is the way to meet other companies and to get advice through their boards on what to do.
Another piece of good advice is to identify the people who are doing Systems Engineering without knowing it, or potential people who can do that. Establish a community of people who on the one side know the product, and on the other side know the new people who are doing Systems Engineering because this might not match together.
Train people into Systems Engineering and anchor Systems Engineering as a mindset – if people believe it, they will do it. Last but not least, people should be good leaders to be successful in promoting SE.

Well, this is interesting. So, these people who are identified in the beginning should have a leadership potential?
Yes, otherwise they’ll be only seen as the specialist and nobody will really see what they do. And how can you introduce SE into a project in that case? It is important that a systems engineer has the soft skills and is not only a typical expert. Yes, I would even say you should not start with a typical Systems Engineering expert because the problem with the introduction of SE will be in disseminating the systems thinking, the systems mindset. So, if the guy is only an expert you will fail probably.
Well, that is my view.

This is a really thought-provoking remark for the closing of our interview. Thank you very much for your time and the interesting talk.