This year's Nordic Systems Engineering tour is special in the sense that is presents the road to the EMEASEC 2026 conference also to be held in Linköping. The tours starts in Hamburg and travels to Copenhagen before finishing at the Linköping Konsert and Kongress - the EMEASEC venue. 

So, this yearNoSE is the small preview of the bigger EMEASEC conference. Still the program is an exiting mix of Systems Engineering related topics. Join us for an exiting Systems Engineering day!

Presentations

Ruslan Bernijazov (AI Marketplace): AI-Augmented Systems Engineering: From Requirements to Architecture and Beyond

Erik Herzog (Saab): Building the Systems Engineering Clan

Daniel Ersson (Saab): Right-Sizing Systems Engineering

Tom Strandberg and Jan Johansson (CAG Syntell): Innovation Debt: A Systems Engineering Perspective on Missed Opportunity

Linda Cederberg, Marianne Klang, and Marianne Johansson: From young engineer to senior Balthazar: What makes young engineers stay and grow within a systems engineering organisation?

Program detail

From young engineer to senior Balthazar: What makes young engineers stay and grow within a systems engineering organisation?

Linda	Cederberg
Marianne	Klang
Marianne	Johansson

Abstract: The paper focuses on understanding the needs of young engineers within a systems engineering organisation. The result from a survey that was conducted among young engineers within aerospace and defence industry in Sweden is analysed, and suggestions for structured way forward for the organisation are given. The main result is that young engineers want support and a clear engineering career, with possibilities to grow stepwise into a role. We do not see a restless young engineer generation, instead eventual reasons for leaving the company in the future is rather a symptom of a non-functional workplace. A crucial aspect is to give the development of engineers as much attention as the development of line managers and project managers – it is all about giving the young engineers good reasons to stay.

 

Innovation Debt: A Systems Engineering Perspective on Missed Opportunity

Tom	Strandberg
Jan	Johansson

Abstract: Too often, systems engineering is associated with a focus on strict processes and "building the system right" (verification) while the even more important contribution, "building the right system" (validation), is overlooked. With this presentation, we want to highlight the innovation opportunity that comes with the application of systems thinking and engineering.

This interactive presentation explores innovation debt as an emerging systems engineering concept for understanding the business consequences of insufficient technical-system exploration. While technical debt is commonly understood as the future cost created by expedient implementation choices, innovation debt is proposed here as the lost business opportunity that accumulates when organizations converge too early on a technical solution without adequately exploring the problem space, solution space, architecture alternatives, interfaces, and lifecycle implications.

The presentation treats innovation debt as a concept that is still evolving, not yet established in the systems engineering literature in the same way as technical debt. However, it can be grounded in recognized systems engineering principles. In particular, the INCOSE Systems Engineering Handbook v5 provides an important reference through its discussion of the System Innovation Ecosystem Pattern, which presents innovation as an ecosystem phenomenon spanning the engineered system, the life cycle project system, and the enterprise process and innovation system. This perspective supports the view that missed opportunities arise not only from weak implementation, but also from limited system understanding, narrow architectural framing, and insufficient exploration of alternatives.

The session argues that a systems approach is essential for reducing innovation debt. Systems engineering emphasizes mission and business analysis, exploring the system context, identify lifecycle scenarios, defining stakeholder needs before setting requirements, viewing system architectures from different perspectives, performing functional analysis to support the generation and evaluation of alternative solution concepts. These practices help organizations avoid premature lock-in, preserve future options, and identify higher valued capabilities before architectural choices become expensive to reverse.

To make the concept tangible, the presentation uses a practical technical-system example to show how a design may appear successful while still creating innovation debt because the wider system was not explored. Participants will then be invited to identify which stakeholders, interfaces, lifecycle stages, and architectural alternatives were overlooked, and what business opportunities were lost. The session concludes by engaging the audience in identifying concrete systems engineering practices that can enhance innovation and minimize innovation debt.

Right-Sizing Systems Engineering

Daniel

Ersson

Abstract: In many ways there are now a wealth of best practice information on how to perform high quality Systems Engineering – process standards, methodology definitions and supporting languages and tooling. Yet, mastering complex system development is still as challenging as ever. This paper reviews the problem of right-sizing Systems Engineering based on experience gained in a large development project. Four distinct development teams are introduced and their outcome analysed. Based on this analysis, a number of factors influencing the adaptation of Systems Engineering for a specific development activity are identified. The purpose is to facilitate analysis on how to right-size Systems Engineering activities throughout development. Based on this, recommendations are formulated for tailoring the Systems Engineering ambition, and applied to the needs of the four specific teams. Team success lies with the ability to take correct decisions with incomplete information at hand. This experience-based skill is hard to teach, however is a core capability in any successful Systems Engineering organisation.

AI-Augmented Systems Engineering: From Requirements to Architecture and Beyond

Ruslan

Bernijazov

Abstract: Generative AI is beginning to change how system descriptions are created, explored, and refined. In Model-Based Systems Engineering, the promise is not limited to faster model creation. AI can also make formal engineering workflows more accessible, support the transition from requirements to functional analysis and architecture synthesis, and reduce the effort required to understand, explain, and evolve complex system models.

This presentation distills recent work on AI-augmented systems engineering from benchmark-based research, practical prototyping, and lessons learned in real modeling scenarios. It shows where current large language models already provide clear value in MBSE, for example in interpreting requirements, suggesting model structures, explaining existing models, refactoring model content, and supporting routine engineering tasks. At the same time, it also addresses current limitations, especially in method understanding, model consistency, context retention, and semantically precise modeling.

A central focus of the talk is how AI support in MBSE can become more dependable. We will discuss how retrieval-augmented generation, structured memory, rule-based validation, and human-in-the-loop interaction can improve reliability and make AI-generated results more explainable and trustworthy. We will also look at how traceability can be maintained or generated when AI contributes to engineering artifacts, and how benchmark-driven evaluation can help qualify AI support for productive use in MBSE.

Finally, the presentation looks ahead to the next wave of AI-supported systems engineering. Agentic workflows, tool-augmented reasoning, and multimodal inputs such as text, sketches, slides, and BOM-related information open new possibilities for impact analysis, cross-artifact consistency, reporting, and data integration across the digital thread. These perspectives will be illustrated in the final part of the presentation through Tessa, our AI assistant for architecture-centric systems engineering, including an interactive modeling session with the audience.

Building the Systems Engineering Clan

Erik

Herzog

Abstract: The corporate landscape is populated by members from different clans where each clan has its own set of beliefs and values. Some examples in an aerospace industry would be the Software clan whose followers firmly believe that an aircraft is a computer on wings, whereas the large and fragmented mechanical engineering clan knows everything about the wings, airframe, aerodynamics, stress and associated basic supply systems (e.g., power, cooling, hydraulics). Then there is the project management clan whose followers are, of course, devoted to the cult of the plan. There are also more esoteric, but influential, clans like the Hero clan whose member beliefs are grounded in the infallibility of the individual hero fixing all problems. Of course, the hero clan is a loose confederation of individual self-proclaimed heroes, but a clan still. Interclan conflicts are frequent and fierce as are intra-clan ones and no pardon is given to apostates and those banned.

On a system level there are several competing clans, e.g., the Agile, Lean and not least the Systems Engineering clans. As with all the other clans they loathe each other and compete for the attention of the greater gods, also known as upper-level management.

The Systems Engineering clan is particularly vulnerable in this clan landscape. Typically, Systems Engineers are distributed across the organization, as opposed to the engineering discipline-oriented clans. Moreover, the entry criteria for acceptance into the Systems Engineering clan are not clear cut. Often Systems Engineering clan members have their origin in other clans. Over their career they gradually and unconsciously evolve into Systems Engineers, but that does not automatically translate to formal clan membership. For success, the Systems Engineering clan must be created and nurtured over time to ensure strength and resilience.
As a committed member of the Systems Engineering clan, I would argue that we, the noble Systems Engineers, have a special place in the intricate clan fabric as the architects, mediators and integrators. In order to take this role the Systems Engineering clan need to adopt three critical skills
- An adequate understanding of the strengths and weaknesses of the proposition of each clan
- An inclusive mindset promoting situational advice
- Patience and humility. In the stressed corporate daily life, the advice of Systems Engineering clan members will not be automatically accepted. Thus, the Systems Engineers clan must carefully analyse progress, learn from success and failures and always be ready for the next opportunity
Clan creation is a necessary condition for the success of Systems Engineering in an organisation, but not sufficient. There is also the need to constantly to hone individual and clan skills such that the Systems Engineering value proposition grows stronger over time.

This presentation will illustrated the concepts outlined above with Systems Engineering related examples from Saab Aeronautics.