Development of Systems Engineering People to

support Major Transformation Plans in Thales

(Process, Roles, Methodology & related tools)
Odile Mornas

Catherine Laporte Weywada

Thales Universit
odile.mornas@thalesgroup.com

Thales Universit
catherine.laporte@thalesgroup.com

Roland Mazzella

Anne Sigogne

Thales Global Services

roland.mazzella@thalesgroup.com

Thales Global Services

anne.sigogne@thalesgroup.com

Patricia Pancher
Thales Universit
patricia.pancher@thalesgroup.com
Copyright 2012 by O.Mornas, C.Laporte-Weywada, R.Mazzella, A.Sigogne, P.Pancher. Published and used by INCOSE with permission.

Abstract. Thales is a major actor as systems provider both on civil and military electronic
domains. Engineers innovate, design and develop System Solutions, economically viable, and
compliant with Stakeholders needs.
For Thales, transformation plans are going on to improve performance and quality in Systems
Engineering: it concerns a new Enterprise Reference system, named CHORUS 2.0 including
redefinition of roles and processes, but also enhancement of methods and tools for
Model-Based Systems Engineering and risks mitigation.
Thus, many concerns are about HR issues. Thales has defined dedicated career paths for
Systems Engineering. Staffing people on critical SE jobs have been developed and are
deployed for all the entities of the Company.
This paper presents the strategy implemented by Thales to support this critical challenge.

1 Systems Engineering major transformation plans in Thales

1.1

A common Enterprise Reference System CHORUS 2.0: simple and unified

In a highly competitive market, when operational performances are a key issue, an
Enterprise Reference System shall facilitate efficient and collaborative work of its employees
through simple, efficient and consistent processes, identifying clear responsibilities at any level
and for any activity.
Moreover, for an international Company involving lots of entities, many stakeholders in
a single project, a same Enterprise Reference System shared, agreed and strictly applicable is a
strong guarantee for consistence and quality.
Furthermore in Thales, the new Enterprise Reference System CHORUS 2.0 is an
opportunity to embed the best practices collected throughout the Company and to make sure
they are applied consistently all over the different activities and countries. Its content has been
designed by enterprise people for enterprise people.
CHORUS 2.0 is an updated version of CHORUS deployed since 2006 based on a BPMN
Business Process Modeling Notation- approach. This first version intended to federate the
Enterprises processes and to facilitate the access to the information through an Intranet portal.
That was a great step (about 20 processes supported by more than 3000 documents) but not
sufficient
Thus, main changes attached to CHORUS 2.0 concern basics in Engineering activities and

interfaces with Bids & Projects Management. The goal is to improve the reliability in delivery,
reinforce customer satisfaction, reduce the costs especially Non Quality Costs and increase
the competitiveness.
Six main stakes characterize this new Enterprise Reference System:
Simplify and unify the Enterprise Reference System (structure, content, and
format).
This Enterprise Reference System is structured by process.
For each process, it defines the organization, rules, practices methods and tools to be used.
Each of these processes is structured in a logical flow of activities and decisional milestones.
CHORUS 2.0 procedures and related instructions share a common template (less than 10
pages, a flowchart of no more than 1 page, key process milestones, roles and responsibilities of
key players). CHORUS 2.0 processes aim at complying with international standards (ISO, SEI,
etc.) to avoid multiple certifications and ensure Customers needs satisfaction.
This Enterprise Reference System is accessible via an Internet-based Enterprise portal
providing notably a semantic search engine on the reference system content. Moreover, the
portal can be customized to define a user profile in order to orient the portal usage, search logic
and data presentation.
Clarify roles and responsibilities.
CHORUS 2.0 defines the roles and responsibilities of key players. The key roles as far as
Systems Engineering is concerned are described hereafter in dedicated paragraph 1.5. Many
difficulties in the past occurred, due to unclear sharing of responsibilities between management
and technical experts, between bids and projects teams Now, decision reviews, arbitrations
and risks management have to be practiced according to clear directives of the Enterprise
Reference System.
Favor teamwork through will of homogeneousness
All processes use the same format, wording and vocabulary to ensure each actor to understand
as well his applicable process as those of the other stakeholders thanks to this same way
approach. Typically, reviews have been renamed consistently for different engineering
activities. This homogeneousness has significantly facilitated their practice.
Master risks through systematic application of basics.
CHORUS 2.0 helps to reduce the risks making sure shared and consistent processes and
procedures are applied throughout the Enterprise. This guides teams to manage bids and
projects more effectively. So it ensures to better satisfy customers in terms of costs, timelines
and performance by leveraging the underlying efficiency gains in engineering, production, and
supply chain management.
Share common processes at Group level while taking into account Business
Models, Countries, Business Lines, specifics, etc.
CHORUS 2.0 aims first and foremost to simplify and unify content, while accommodating the
specificities of each company, country and function. Operational staff will find simple
processes to help them doing their jobs better and working together more efficiently,
It is also an opportunity to improve the internal organizations and align the practices within
companies and countries, between countries, and between countries and companies. And that
benefits the whole Enterprise.
CHORUS 2.0 describes the fundamentals i.e. the core processes that must be applied
throughout the organization. These processes may be adjusted as necessary and justified,
according to the specific constraints of each company, country, function and activity.
Disseminate internal and external best practices
CHORUS 2.0 is designed as repository and tooled-up guidelines for Bids and Projects staffs to

implement the Thales Group best practices. A project engineer uses it to examine each aspect
of a products life cycle, from product policy and Enterprise strategy to the different steps
involved in developing suitable solutions. A Sales person can access all the elements of a Bids
life cycle, from strategic considerations to contract terms and conditions. CHORUS 2.0 is a
way to help employees perform their day-to-day tasks.
Processes definition has been challenged, facing external standards or references as IPMA for
Project Management, ISO 9000 for Quality Management, CMMI for assessment models,
INCOSE SE Handbook, and ISO/IEC-15288 for Systems Engineering Technical Management,
1.2

A dedicated process to Design, Develop and Qualify the Solution (DDQS)

within a shared framework
CHORUS 2.0 covers all the processes of the Enterprise with only 9 processes at the top level,
split in 3 different topics:
4 of them concern Strategy and Control,
4 of them concern Operational Core, including DDQS,
1 is about Support.
Manage
and Control

Manage
Competences

Continuous
Improvement

Manage Bids & Projects

Design, Develop and Qualify the solution

Source and Make

Prepare and Deliver Customer Service

Customer and final user

satisfaction

Customer and final user needs

Define the
strategy

Support operational processes

Figure 1. The CHORUS 2.0 Top level Process Map

One of the operational CHORUS 2.0 processes is DDQS as Design, Develop and Qualify the
Solution (Solution addressing an operational System, a product, enabling systems and/or
services).
The DDQS Process is conducted with a Concurrent Engineering and Co-Engineering
approach.
The objective of DDQS process is to describe engineering activities and responsibilities, to
achieve customer satisfaction of the delivered solution in consistency with product policy,
technical strategy and Make / Buy strategy.
The management of the involved engineering activities must ensure the achievement of
applicable functional requirements, non-functional requirements (e.g. performance,
dependability, human factors), and constraints (development schedule and cost, norms and
standards, legislation, regulation).
Moreover, producibility of the solution (in compliance with required performance schedule

(lead time) and cost) as well as it sustainability (through service life in terms of technical
performance, operational availability and through life cost of ownership) shall be ensured.
To reach these objectives, DDQS focuses on following key points:
The first key point is dedicated to new roles: Design Authority (DA) [Division and
Product view] and Project Design Authority (PDA) [Project view] roles (see below).
The second key point consists in integrating disciplines: promoting collaborative and
concurrent engineering (Specialty engineering, System/HW/SW, involving:
Purchasing, Production, Through-Life Support, Quality ): reviews and decisions
attached to elements of lower levels are closely linked all together.
The third key point focuses on improving consistency within the DDQS process and
consistency with other related processes (Bids and Projects, Engineering, Production &
Service), to avoid any conflict or mismatch (see Figure 2 below).
The fourth key point consists in integrating field proven best practices,
Finally, Moreover, DDQS focuses on reinforcing architecting and reinforcing early
preparation of Integration, Verification, Validation and Qualification.

Closure R

KOM

5.1 Manage the bid

Launch R

Gate 3

Gate 2

CCR

BBR

Gate 1

Contract
Entr y into Force

End Production

5.2 Manage the project

FQR

TQR

TRR

CDR

PDR

SFR

SRR

SOR

SOR3

SOR2

SOR1

Solution

6.1 DDQS

Solution Element

7.2 Procure,
8.1 Design
& Deliver
Customer
Service

PCA
FCA

Make & Deliver

Component(s)

PRR
First batch
(tested items)

Prepare
(tested items)

FAI

Plan, Make
(tested items)

PRR
Next batches
(serial items)
Service Definition
Review
Define Customer Service

Prepare
(serial items)

Deliver
(if testeditems are delivered)

FAI
Plan,Make
(serial items)
Service Deployment
Validation Review

Deploy Customer Service

Deliver
(serial items)

Deliver
Deliver
& Optim
& Optim
ize ize

Figure 2. Collaborative and concurrent approach for Systems Engineering in CHORUS 2.0
1.3 An Integrated Approach to mitigate risks
The development of a System from concept development to delivery of the solution for
production or operation, involves finding the right trade-off between conflicting requirements
and constraints. The system has to satisfy needs, expectations and constraints of all
stakeholders. Moreover, it must be acceptable for its environment (physical, social and
ecological aspects, all along its life cycle including maintenance and disposal). It shall
constitute a balanced and optimized solution throughout its life cycle, while incorporating

provisions for reuse in future solutions. Following Figure 3 illustrates the amount of involved
and interlaced processes all along the stages of this life cycle.

Figure 3. Engineering activities along the Solution lifecycle [1]

Instead of facing lately different and inconsistent constraints concerning performances,
security, human factors, etc the Systems Engineering approach consists in iteratively
integrating the contributions and viewpoints of all the concerned stakeholders, in order to
reconcile the viewpoints and move towards an optimized solution, satisfying the best
compromise, while justifying each successive decision on the basis of an overall analysis of the
consequences.
It is usually impossible to define a complete solution straight away: solutions have to be
broken down iteratively into subsystems and interactions have to be taken into account until an
answer is found through Solution elements (existing components or components requiring
development).
The next problem to address is to determine how to integrate these elements. This
involves defining functional and physical architectures. That means determining main
functions as well as physical components of each concerned system which enable these
functions to be performed.
The architecture also has to take into account systems non-functional requirements and
characteristics, notably constraints specific to its context of use (safety, security, human
factors, environment, performance, reliability, etc); each of these constraints having a
significant impact on the technical solution.
1.4

Thales Systems Engineering Method aligned with the Enterprise

Reference System
In addition to this common Enterprise Reference System identifying applicable Processes,
Thales Group has defined its own Systems Engineering methodology (named Sys-EM). It
provides with whole Systems Engineering activities useful guidance (typically, field proven
approaches) to perform required CHORUS 2.0 activities in a methodological way:
What to do and why: best practices coming from Thales lessons learnt and outside
Thales, key points to address,
How to do: pragmatic guidance (methods, templates, checklists, etc.)
What environment: tooled-up process implementation needs and/or recommendations.

ISO 9001:2000
Standards
of the discipline

CMMI Dev
ISO/IEC--12207
ISO/IEC

CHORUS II:
Enterprise
processes

ANSI/EIA--632
ANSI/EIA
Outside Thales
Best
Practices

Sys-EM:
Engineering
processes

Process
Assessment
Thales
Best
Practices

ISO/IEC--15288
ISO/IEC
IEEE 1220
Common Source
Standards

Sys-EM
documents
Needs for
tooled
processes

Figure 4. Sys-EM positioning against CHORUS 2.0 Reference System

Sys-EM is deployed for more than ten years in the Company, collecting and highlighting best
practices in any Thales fields, capitalizing experience in Aeronautics, Transportation, Space,
Telecommunication, Air Traffic Control, etc.
Sys-EM and its associated assets (detailed guidance) have evolved from the proven practices of
Thales in Systems Engineering, and continue to evolve and improve through adding new
practices assessed by Thales Units and/or international System Engineering community.
Thales participates in many working groups at international level to examine the interest of a
convergence between INCOSE referential and its own referential (Thales has members
involved in INCOSE organization and certified at CSEP or ESEP level).
Sys-EM has several objectives:
first one is to maintain a common Enterprise culture for Systems Engineering
throughout the Thales Group and improve the efficiency of systems development
within the organizations,
second objective is to provide a shareable process framework easily adjustable to
domain, organization and project needs,
third objective is to define a way to do Systems Engineering respecting common
standards (e.g. ISO/IEC-15288 [2] and EIA-632 [3]) and to comply with technical
processes of CMMI level 2 and 3 requirements [4] & [5], notably to facilitate work in
partnership,
fourth objective is to establish and share efficient practices,
fifth objective is to allow collaborative working across Thales Group but also with
external organizations and governments.
For continuous improvement of Sys-EM, consistency with INCOSE products (SE Handbook
[1], working group products.) is regularly checked as source of future updates.
Sys-EM specificity is to integrate both Requirements and Model Based approaches, including
requirements & tests management.
Thus it refers and valorizes Architecting, based on Architecture Frameworks already used by
some major customers (standard such as MODAF, NAF or TOGAF are currently used in
Thales) as well as Architectural Design. This topic is addressed by a Thales Architecture
Analysis and Design Integrated Approach called ARCADIA (with an associated tool called
MELODY ADVANCE). ARCADIA [6] [7] aims to support all steps of Architectural design
from operational needs analysis, then system (functional and non functional) analysis, leading

to logical and physical architectures and finally the definition of System EPBS (as End-Product
Breakdown Structure) while preparing related IVV activities.
To deploy efficiently this approach, this requires a very precise relevance between the
roles, the competencies and the processes.
1.5 Clarification of roles in Systems Engineering
CHORUS 2.0 clearly identifies the responsible party presented in the processes, management
plans or delegation memos.
Design Authority and Project Design Authority roles and responsibilities have been
defined as necessary to enforce the confidence of development work-products regarding both
final Customer and Enterprise needs.
This also means that no serious commitment can be taken in the earliest phases of the
Bid without a formal approval of the Design Authority.
Consequently, the following Systems Engineering roles have been described:
The Design Authority (DA) is delegated by the Division for a Bid/Project.
He/she is Responsible for Solution approval for Bid and Project Phases, verifies consistency
with Product Policy, technical strategy & Make/Team/Buy strategy and verifies the Risk
assessment and challenges the Solution.
The Project Design Authority (PDA) is a Bid/ Project team member.
He/she has the technical responsibility within the Bid/Project, ensures that
the technical decision regarding the Solution satisfies needs and concerns
of the stakeholders, in line with Product Policy technical strategy and
legislation & regulations, ensures that technical risks are identified and
mitigated.
The Architect (ARC) is a Bid/ Project team member. He/she is
responsible either of architecting of the Solution in the orientation phase and/or the
architectural design during the development. He/she analyzes technical and technological
choices to optimize the trade-off between Stakeholders requirements, technical solutions &
cost/risks, ensures standardization and adequate re-use as defined by the PDA.
The Systems Engineering Manager (SEM) is a Bid/ Project team
member. He/she is Responsible for preparing and performing all Solution
Engineering activities according to agreed Solution strategy
Ensures System Engineering activity management within
constraints provided by approved architecture and design policy.
Plans and coordinates the whole System Engineering activities
within the constraints provided by the agreed architecture and
design policy in order to satisfy customer and other stakeholders requirements.
Defines WBS, OBS and associated tasks, tailors development process and ensures
achievement of the development baselines (functional, allocated and product),
including those flown down to subcontractors and partners.
Manages Risks & Opportunities of design and development during bid phase,
guarantees Project commitments, including those flown down to subcontractors and
partners.
Optimizes technical work against costs, schedule and risks from design to validation
and acceptance of the solution.

The Integration/Verification/Validation/Qualification Manager (IVVQM) is a Bid/

Project team member. He/She is responsible for preparing and performing Solution IVVQ
activities
Prepares Solution Integration Verification Validation & Qualification activities, in line
with the overall Development Strategy
Ensures the management of the Solution Integration Verification Validation &
Qualification activities.
During bid phase, defines IVVQ strategy, establishes requirements related to IVVQ
activities and performs associated cost estimate and schedule.
Specifies, selects and deploys methodologies (including metrics), tools/platforms
necessary to IVVQ and acceptance activities.
Proposes IVVQ scenarios and guaranties their implementation
Coordinates IVVQ activities, establishes priorities and integration logical diagrams,
conducts factory tests and on site at the customers premises, as well as commissioning,
analyses results and transmits them to development teams.
The picture below highlights the different and various interfaces for these five main roles for
which clarification in responsibilities was really an issue.

Design Authority

Contract
manager

Bid/Project
Manager

Customer

Work
Package
Manager
Acquisition
Project
Manager
SubContracts

Acquisition
Technical
Support

System
Engineering
Manager

IVVQ
Manager

System
Engineer) Specialty
Engineer

Subsystems

SW
Eng.

HW
Eng.

Installation
Manager
Production
Process &
Techno.
Manager

Architect

Contract

End
User

Project Design
Authority

Product Line
Manager

HW
Engineering
Manager

Quality
Manager
Support
Manager
Configuration
Manager
Service
Eng.
Environment
Manager
Manager

SW
Engineering
Manager

Figure 5. Organization & Roles for bid/project

The brown central box covers the whole integrated engineering team; internal interfaces are
implicit and are defined by an Engineering team charter.
From these definitions, Thales has to tackle with the staffing of the teams and to anticipate on
the future needs of the Company.
It means that, in order to deploy the new Enterprise Reference System for more than 65 000
employees (with 10 000 Systems Engineers), and insuring the good understanding and the
good application on projects, the change management is a crucial issue, involving HR actions.

2 HR Management of the Systems Engineering Job family

SE Competency is built from knowledge, skills, abilities, and attitudes (KSAA). These are

developed through education, training, and experience. Traditionally, SE competencies have

been developed primarily through experience. Recently, education and training have taken on a
greater role in the development of SE competencies. SE competency must be viewed through
the relationship to the system life cycle, the SE discipline, and the domain in which the
engineer practices SE. [8].
2.1 Career evolution in Systems Engineering
Thales has an ambitious approach to manage its different Job Families. Lets focus on the
Systems Engineers.
The Enterprise has to identify its Key-Issues for the coming years, the profiles and
competencies of the System Engineers (detailed figures, age curves, collect of individual
competencies based on a structured model (based on SE competencies Models [9], [10], [11]),
internal and external mobility feeding the Job Family, main trends for recruitment) and the
Actions Plan to cover the objectives.
Of course, all these trends have to be aligned with the new Reference System previously
defined.
The figure below illustrates the established career path for Systems Engineers: main
orientations inside to move from a junior System Engineer to a recognized expert or a SE
manager for example. This is a very important and relevant reference model to promote the
jobs, motivate people in real opportunities of career, with formalized progress paths in the
System Engineer & Architecting area and bridges towards others like management or
marketing.
This approach, of course, is iterative: based on a corporate model, it is collected at
entity or country level and consolidated at Enterprise level, defining therefore the global needs
and the strategy and the relevant evolutions that are now really challenging for Thales.
It also facilitates a better identification of the experts with their own specialty, ensuring Tiger
Teams can be staffed on critical issues.
> Career evolution
Move towards Bids and projects job
family

CC
CC Manager
Manager
(Competence
(Competence
Centre)
Centre)

Technical
Technical
Director
Director

Common moves within the System

engineering job family

System
System Architect
Architect

HoD
HoD
(Head
(Head of
of
Discipline/Dept)
Discipline/Dept)

(Design
(DesignAuthority
Authority-Project
Project / / Product
ProductDesign
Design
Authority)
Authority)

System
System
Engineering
Engineering // IVVQ
IVVQ
Manager
Manager

System
System Architect
Architect
Operational
Operational Expert
Expert
Speciality
Speciality Engineer
Engineer and
and Expert
Expert
Intellectual
Intellectual property
property Manager
Manager

System
System
Engineer
Engineer
Specification
Specification &&
Design
Design

System
System
Engineer
Engineer
IVVQA
IVVQA

System
Engineer
System Engineer
Process,
Process, Methods
Methods and
and
Tools
Tools

System
System
Engineering
Engineering
Team
Team leader
leader

System
System Engineer
Engineer
(generalist)
(generalist)

Figure 6. Thales Systems Engineering career typical evolution

2.2 Systems Engineering Training Path
One strength of Thales is to possess its own Centre for training its employees called Thales

Universit. This centre is training internationally with locations over 8 countries. It addresses
more than 15 000 employees per year, delivering around 50 000 training days per year.
Thales Universit designs inventive approaches for training mixing business cases,
learning expeditions, business cases. Various pedagogic means and resources includes blended
learning, e-learning and virtual classrooms in order to satisfy the operational needs.
The training offer covering all Job Families existing in the Enterprise is designed and regularly
updated to fit Thales issues:
Either to deploy a common strategy (e.g. CHORUS 2.0 deployment up for 65 000
people is a typical challenge for Thales Universit, dedicated training for Managers and
Experts, Welcome conventions for new comers),
Or to facilitate networking inside the Company, train on Thales methods and tools
including best practices collected in the different domains as well to train on new
trends, missing in the external offer.
Lets say that Thales Universit is the privileged training partner for the Enterprise!
Of course Systems Engineering needs are a high priority in Thales Universit. The training
offer has to address all the Systems Engineering & Architecting roles: Design Authorities,
Systems Engineering Manager, System Architect, IVVQ Manager, Support/Methods and
Tools Manager, Specialty Engineer, Expert and every SE practitioner. The goal is supporting
him/her all along his/her professional development, facilitating his/her evolution or mobility
and guaranteeing his/her employability.
Expert
Expert Leadership
LeadershipProgram
Program
ELP
ELP15
15

Technical
TechnicalLeadership
LeadershipProgram
Program
TLP
TLP10
10

System
System // product
product
Architect
Architect

Senior
Senior System
System // Engineering
Engineering

System
System
Architects
Architects
ARCSE
ARCSE55
Architecture
Architecture
Frameworks
Frameworks
AF
AF33

System
System // product
product
Designer
Designer
Melody
MelodyAdvance
Advance
SE
SE
MELOSE
MELOSE33

Arcadia
Arcadia11

Passport
Passport System
System
Architect
Architect
PARCHI
PARCHI44

SE
SEfundamentals
fundamentals
@learn
@learn

Technical
Technical
Manager
Manager

Advanced
Advanced
Systems
Systems
Engineering
Engineering
SEA
DV 33
SEADV

Requirements
Requirements
Analyst
Analyst
Orchestra
OrchestraDoors
Doors
TrekTrek- ORCDO
ORCDO11

IVVQ
IVVQ Engineer
Engineer

IVVQ
IVVQPractitioner
Practitioner
IVQ
IVQ33

DOORS
DOORSTrek
Trek
@learn
@learn

Interfaces
Interfaces&&
Interactions
Interactions
INTERFC
INTERFC11

Configuration
Configuration
Manager
Manager

PLM
PLMw
with
ithPALMA
PALMA
CMPALMA
CMPALMA33

EcoDesign
EcoDesign
ECODES
ECODES22

Integrated
Integrated
Logistics
Logistics Support
Support
ILS
ILS@learn
@learn

Hum
Human
an Factors
Factors
Issues
Issues
HFI
HFI33

Design
Designto
tocost
cost
FCCO
FCCO33

Safety
Safety
RAMS
RAMS33

Creativity
Creativity
CREA
CREA22

Configuration
Configuration
Management
Management
CMPROC
CMPROC33

Engineering
Engineering

Sys-EM
Sys-EM
@learn
@learn

Passport
Passport Sub
Sub
Contract
Contract
Management
Management
PSCM
PSCM 33

Transverse
Transverse activities
activities

Passport
PassportSystem
System
Engineering
Engineering
PSYSE
PSYSE3.5
3.5

Orchestra
Orchestra
overview
overview
@learn
@learn

Orchestra
Orchestraquick
quick
start
startfor
for System
System
Engineering
Engineering
ORCSE
ORCSE22

SE
SETechnical
Technical
Management
Management
SETM
SETM 44

Passport
Passport Work
Work
Package
Package
Management
Management
WPM
WPM 33

Management
Management
Smart
Sm artPlatform
Platform
Orchestra
Orchestra
Training
Training
SPOT
SPOT33

Common
Common training
training
Key program

Figure 7. Training offer in Systems Engineering

The picture above illustrates the diversity of the offer, addressing technical topics, technical
management, including soft skills [12].

It has to be read from bottom to top with basic training for junior then dedicated training for
technical skills (on the left) or for System Engineering Managers & IVVQ Managers (on the
right). Some other courses, classified as Transverse activities focus on specialty engineering
such as safety, human factors, The Systems Engineers have to know important aspects of the
specialties, but they have also to know how to integrate the technical knowledge of the
specialists into their project.
Each of these different modules is less than 5 days. Trainees can access to such or such
modules after validation and consolidation of the yearly training plans in the entities.
The paper will focus on three different Key Training Programs:
Passport System Engineering
Passport System Architect
Systems Engineering Technical Management
SE Architect
Design Authority

SE manager
IVVQ manager

2011
Passport
Passport
Systems
System
Systems
Architect
Architect
PARCHI
4days
4days
PARCHI
4days

SE Engineer
IVVQ Engineer
Designer

System
System
Engineering
Engineering
Technical
Technical
Management
Management
SETM
4days
4days
SETM
4days
2009

2011

Passport
System
Systems
Passport to
to
Systems
Engineering
Engineering
PSYSE
3,5days
3,5days
PSYSE
3,5days

Figure 8. Key programs in the Training offer for Systems Engineering

The two first have been designed and are delivered with the support of external consultants,
e.g. IPMC, specialized in training and consultancy for Systems Engineering and Management
of Complex Projects.
2.2.1 Passport Systems Engineering
This training has been delivered to more than 2 000 engineers in the Enterprise for four years.
Trainees practice during four days the full development lifecycle of a system from
specification to manufacturing activities with testing per stages.
For each session 3 groups of 12 trainees, close to an operational team with different SE roles,
are competitors to specify, design, deliver and test a LEGO vehicle, consistent, of course
with Thales processes and methods (lifecycles, documents, reviews, roles).
Trainees have to face a Customer for possible negotiation, capture, analyze and structure
Customer needs, taking into account different kinds of constraints (reuse,..), formalize
requirements, strongly design using recognized techniques and methods, apply change
management facilitated by a rigorous traceability, approach design to cost, prepare IVVQ
activities very early in the lifecycle, manage the whole activities thanks to a Systems
Engineering Manager
These are some of the components of this training that is now a key basic training to deploy and
broadcast Thales Reference System all over the Enterprise.
This course is addressing junior Systems Engineers or Engineers specialized in a

specific domain (test, studies) and gives to them a good understanding on the issues and a
better appropriation of the added value of common practices in the Enterprise. It trains on the
different activities and their actors including the soft skills (team spirit, rigor, justifications,
decision making). It is recognized for its efficiency and innovative pedagogy.
2.2.2 Passport System Architect:
Last born in the offer is for consolidating the basic competencies of the Architect.
With an increasing need of 15-20% of Architects per year, this training is now very structuring
and crucial for the Enterprise.
Regarding that systems to deliver are becoming more and more complex, architecting and
rigorous design are key-activities to formalize bases and principles of the solution. The
Passport to System Architect training course is mainly providing skills for
Stakeholder needs capture,
Architecture description and assessment (with usage of Architecture Frameworks to
describe and evaluate Operational, system and technical views),
Model based Design with the Thales ARCADIA method
Multi-criteria analysis and trade-off techniques
During the session the trainees are playing roles of stakeholders, project managers, design
authority, architect, system engineer, and specialty expert (in safety or security for example).
For each role, the training covers activities, responsibilities, relationships and ability for
collaboration/teaming, integration in different organization schemas and position in decision
chains. Soft techniques are also explained for leadership, mediation with stakeholders and
discipline engineer (software, hardware, etc), arbitration, presentation, consensus-making on a
solution, etc.
The business case designed for this course concerns a meteorological balloon (Earth
Observatory Laboratory Environment). Trainees have to take part in Architecting and in the
Architectural Design of the System, using methods and tools recommended in Thales. All the
reviews, justification documents and decision-making processes are addressed through this
serious game involving all the stakeholders.
Technical choices are based on different criteria (design to cost approach, reuse, Product Line
approach).
The training is planned for nearly 250 people for 2011, the first full year. Its built on many
practical exercises on a business case covering all the activities, and mixed with formal
presentations, feedbacks and testimonies.
2.2.3 System Engineering Technical Management:
In the context of complex systems and constrained equipments (performances, industrial
constraints, assets), the development of such systems has to be highly managed and
mastered.
A dedicated training addresses specifically Systems Engineering Managers and IVVQ
Managers, and is about technical management in Bids and Projects steps on the following
topics:
Development of Solution strategy with a Trough Life Cycle vision,
Technical risks and opportunities management,
Tailoring, estimation, planning, monitoring the different activities,
Staffing and team building, especially for multi-disciplinary teams,
Communication with internal and external stakeholders,
Negotiation (subcontractors, partners),

Awareness on necessary environment (tooling) enabling Systems Engineering

efficiency.

Designed and trained by Thales people, this is illustrated by business cases built on concrete
and real examples, highlighting good but also bad practices to avoid!
2.3 Thales Universit outside Thales
Sharing training is also strategic for Thales for different reasons:
This addresses future engineers and it may promote Thales branding in the Engineering
Schools. Training students on the Passport to Systems Engineering promotes the
discipline and its attractiveness for future recruits,
This may be part of negotiations with Customers, dealing with assets and transfer of
technology: creation of Rail University in Egypt, project of partnership with Khalifa
University for a Master in Systems Engineering with Paris 6 University Universit
Pierre et Marie Curie- can be taken as examples for these actions.
Thales has also a strong commitment to team with Universities and Engineering
Schools in order to develop Research at the highest level with the best Laboratories in
the world. Today this is at least true for France, UK, Nederland, Singapore and
Australia.
Certification of SE people is key for Thales. It concerns both operational people and
Thales trainers, ensuring external recognition for Customers but also challenging
Thales practices: a focus has been done for TOGAF and INCOSE certification.
Thales training foundations are also consolidated by participation in different working groups
within consortia and association like the French Chapter of INCOSE (AFIS) and French MOD
Ecole Systme de systmes.
2.4 Perspectives
Thales Universit training map covers a wide area of knowledge, know-how and awareness on
many topics. It is in line with SE career ladder, with the purpose of ensuring that System
Engineers are armed with and capable of using various SE skills, methodologies and
techniques on the job, for their role, and also capable of tailoring them to their projects.
SE is fundamentally integrative in nature. SE requires a basic understanding of all of
the disciplines required to define, design, implement, integrate, deliver, and manage the entire
system with all of its components through the entire system life cycle. [12].
The main purpose is to enhance the SE behaviors and skills of Thales Staff, a core
competency of Thales group and thereby allow the staff to deliver better products to the
customers.
Contents are regularly revisited and updated according to internal references and
practices but moreover, according to external references.
Our coverage has to be challenged with external references of skills such as INCOSE to
guarantee that we face all the recognized skills.
Many topics have to be investigated in the coming years:
improvement of Systems Engineering through involvement of specialty activities in a
collaborative process,
capability engineering (cf. CAPDEM, through Life Capability Engineering UK
MOD)
services engineering (cf. French Chapter AFIS of INCOSE)
Then, their deployment on the projects will be based on a solid Thales model mixing processes,

actors, guides, methodology, training and support.

3 Summary
The deployment of these different key actions described above contributes to a main part of the
Transformation Plans in Thales, in order to answer new challenges:
Cover new perimeters (multi-countries, cross-entities, multi-partnerships),
Reduce the Non Quality costs,
Address more and more complex systems,
Improve competitiveness by improving the product line approach.
The aim, as far as Systems Engineering is concerned, is a qualitative and global improvement.
Following table 1 summarizes the impacts of the key actions on these challenges
Table 1. Summary of impact of key actions on new challenges (+: impact, ++ high impact)

Impact for
engineering aspects

CHORUS 2.0

Cover new
perimeters
(multi-countries)

Reduce the Non

Quality costs

++

Sys-EM
Tooled up process
Roles
Training

Address more and

more complex
systems

Improve
competitiveness by
improving the
product line
approach

++

++

+
++

++
+

++

++

++

++

++
+

Internal reporting helps Thales to check the deployment of training for the community (around
10 000 people worldwide).
Capitalization on training for Thales can give opportunity to external collaboration.

4 Biography
Odile Mornas: Systems Engineering Product Line Manager at Thales Universit,
After a 25 years experience dedicated to the definition and development of complex C2
systems, then to Systems Engineering Process Definition and Improvement, Odile Mornas is in
charge of design and delivery of Systems Engineering Training. She contributes to the Thales
Group System methodology (Sys-EM). CMMI SEI DEV and ACQ assessor, she contributes
to CMMI assessments inside Thales group.
AFIS and INCOSE member (CSEP certified and CAR)
Engineer (Post grad degree), 1984, ENSMM (Mechanics/Robotics), France.
DEA Automation and Industrial Computing, 1984, Universit de Franche-Comt Besanon
Catherine Laporte-Weywada: Practice Director for Systems and Software Engineering
Training - Thales Universit
After an experience in Total for acquisition (surveys on site, management of oceanographic
campaigns) and data processing for meteorological and oceanographical data for off-shore
structures, she has chosen to orientate her career to training and professional development, as
trainer for Software Engineering, then as Pedagogic Manager in an Engineering School and
now as Practice Director in Thales University. She now covers the internal training (design and

delivery) for Software and System Engineers for the Company.

Roland Mazzella: was educated at INSAT (Institut National des Sciences Appliques de
Toulouse). Engineer in THALES Group, he has over thirty five years experience of
Engineering, first in real time embedded software development and then in Systems
Engineering in both military and civil domains. He is responsible of the Thales Corporate
Engineering Methodology (System, Software and Hardware) development. He is a THALES
expert recognized as ESEP.
Anne Sigogne: After 20 years consecrated to Energy Management System (Supervisory,
Control and Simulation for Electricity, Gas or Oil transportation) in Bids and Projects, then
pre-sales as Senior advisor, currently Systems Engineering Process & method Expert at Thales
Global Services (whole Thales shared services).
Contribute to CHORUS 2.0 DDQS process definition, Sys-EM maintenance and their
deployment in Thales Universit SE trainings.
Member of AFIS/INCOSE, CSEP certified and CAR.
Education: Master of Physics at Orsay University (France), then PHD in Electronics
(simulation of PWR plants regulation) at CEN of Saclay (France)
Patricia Pancher: Product Line Manager within Thales Universit,
Ph.D in images processing at University of Saint-Etienne, she began her career as software
work package manager for development of Human Man Machine interface product within the
Thales group. Then, she worked in the engineering of supervision systems (transportation and
energy plant). Her experience in Thales continued in system engineering processes, methods
and tools improvement, with a major competency in system architecture modeling. She was the
leader of the architecture AFIS working group during 4 years.
Today, she is responsible of Systems and Software engineering training development and
deployment at Thales Universit.

5 References
[1] : Haskins, C., ed. 2011. Systems Engineering Handbook: A Guide for System Life Cycle
Processes and Activities. Version 3.2.2. Revised by M. Krueger, D. Walden, and R. D.
Hamelin. San Diego, CA (US): INCOSE.
[2]: ISO/IEC 15288:2008 Systems and software engineering System life cycle processes
[3]: ANSI/EIA-632-1998, Processes for Engineering a System
[4]: CMMI for Development, Version 1.3
[5]: CMMI for Acquisition, Version 1.3
[6]: Voirin JL. Method & Tools for constrained System Architecting. INCOSE Utrecht,
[7]: Voirin JL. 2010. Model-driven Architecture building for constrained Systems. Complex
Systems Design & Management 2010 (CSDM 2010)
[8]: INCOSE Body of Knowledge V0.5 SEBoK v. 0.5
[9]: INCOSE UK WG - Systems Engineering Competencies Framework January 2010
INCOSE-TP-2010-003
[10]: Metzger, L. and Bender, L. September 1, 2007. MITRE Systems Engineering (SE)
Competency Model, Version 1.13E
[11]: Trudeau, Philip N., Designing and Enhancing a Systems Engineering Training and
Development Program. MITRE Institute
[12]: Graduate Reference Curriculum for Systems Engineering V0.5
GRCSE version 0.5 Release for Global Review December 2011