development of systems engineering people to support major transformation plans in thales

7/24/2019 Development of Systems Engineering People to support Major Transformation Plans in Thales

1/15

Development of Systems Engineering People tosupport Major Transformation Plans in Thales(Process, Roles, Methodology & related tools)

Odile MornasThales Universit

[email protected]

Catherine Laporte WeywadaThales Universit

[email protected]

Roland MazzellaThales Global Services

[email protected]

Anne SigogneThales Global Services

[email protected]

Patricia PancherThales Universit

[email protected]

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 ina 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

sufficientThus, main changes attached to CHORUS 2.0 concern basics in Engineering activities and


2/15

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, theportal 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 understandas 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 BusinessModels, 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 practicesCHORUS 2.0 is designed as repository and tooled-up guidelines for Bids and Projects staffs to


3/15

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.

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 andstandards, legislation, regulation).

Moreover, producibility of the solution (in compliance with required performance schedule

Manage Bids & Projects

Design, Develop and Qualify the solution

Source and Make

Prepare and Deliver Customer Service

Support operational processes

Customer

andfinaluserneeds

Customerandfinaluser

satisfactio

n

Define thestrategy

Manageand Control

ManageCompetences

ContinuousImprovement

Manage Bids & Projects

Design, Develop and Qualify the solution

Source and Make

Prepare and Deliver Customer Service

Support operational processes

Customer

andfinaluserneeds

Customerandfinaluser

satisfactio

n

Define thestrategy

Manageand Control

ManageCompetences

ContinuousImprovement


4/15


5/15

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 bebroken 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 EnterpriseReference 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.


6/15

Process

Assessment

CHORUS II:

Enterpriseprocesses Sys-EM:

Engineering

processes

Outside Thales

Best

Practices

Standards

of the discipline

Sys-EM

documentsNeeds for

tooledprocesses

Thales

Best

Practices

ISO 9001:2000ISO 9001:2000

CMMI DevCMMI Dev

ISO/IECISO/IEC--1220712207

ANSI/EIAANSI/EIA--632632


IEEE 1220IEEE 1220

Common Source

Standards

Process

Assessment

CHORUS II:

Enterpriseprocesses Sys-EM:

Engineering

processes

Outside Thales

Best

Practices

Standards

of the discipline

Sys-EM

documents

Sys-EM

documentsNeeds for

tooledprocesses

Thales

Best

Practices

ISO 9001:2000ISO 9001:2000

CMMI DevCMMI Dev


ANSI/EIAANSI/EIA--632632


IEEE 1220IEEE 1220

Common Source

Standards

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 withexternal 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 calledMELODY ADVANCE). ARCADIA [6] [7] aims to support all steps of Architectural design

from operational needs analysis, then system (functional and non functional) analysis, leading


7/15

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 isresponsible 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 activitieswithin 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 ensuresachievement 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.


8/15


9/15

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.

Figure 6. Thales Systems Engineering career typical evolution

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

> Career evolution

Move towards Bids and projects job

family TechnicalDirector

Technical

DirectorCommon moves within the Systemengineering job family

CC Manager

(Competence

Centre)

CC Manager

(Competence

Centre)

System Engineer

(generalist)

System Engineer

(generalist)

System ArchitectSystem Architect

HoD

(Head of

Discipline/Dept)

HoD

(Head of

Discipline/Dept)

Operational ExpertSpeciality Engineer and Expert

Intellectual property Manager



System Engineer

Process, Methods and

Tools

System Engineer


Tools

System

Engineer

Specification &

Design

System

Engineer

Specification &

Design

System

Engineering

Team leader

System

Engineering

Team leader

System

Engineer

IVVQA

System

Engineer

IVVQA

System Architect(Design Authority -

Project / Product Design

Authority)



Authority)

System

Engineering / IVVQ

Manager

System

Engineering / IVVQ

Manager

> Career evolution

Move towards Bids and projects job

family TechnicalDirector

Technical

DirectorCommon moves within the Systemengineering job family

CC Manager

(Competence

Centre)

CC Manager

(Competence

Centre)

System Engineer

(generalist)

System Engineer

(generalist)

System ArchitectSystem Architect

HoD

(Head of

Discipline/Dept)

HoD

(Head of

Discipline/Dept)





System Engineer


Tools

System Engineer


Tools

System

Engineer

Specification &

Design

System

Engineer

Specification &

Design

System

Engineering

Team leader

System

Engineering

Team leader

System

Engineer

IVVQA

System

Engineer

IVVQA



Authority)



Authority)

System

Engineering / IVVQ

Manager

System

Engineering / IVVQ

Manager


10/15


11/15

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 thespecialists 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

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 LEGOvehicle, 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

IVVQ manager

System

Engineering

ManagementSETM 4days

System

Engineering

Technical


Passport to Systems

EngineeringPSYSE 3,5days

Passport to Systems


SE EngineerIVVQ Engineer

Designer

SE Architect

Design Authority

Passport

Systems

ArchitectPARCHI 4days

Passport

Systems


20112011

2009

SE manager

IVVQ manager

SE manager

IVVQ manager

System

Engineering

Technical


System

Engineering

Technical

Management4days

Passport to Systems


Passport SystemEngineering

3,5days


Designer


Designer

SE Architect

Design Authority

Passport

Systems


Passport

System

Architect4days

20112011

2009


12/15

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 todescribe 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 decisionchains. 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 theArchitectural 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),


13/15

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 EngineeringSchools 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 acollaborative 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,


14/15

actors, guides, methodology, training and support.

3 SummaryThe 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 forengineering aspects

Cover newperimeters(multi-countries)

Reduce the NonQuality costs

Address more andmore complexsystems

Improve

competitiveness byimproving the

product line

approach

CHORUS 2.0 ++ + +

Sys-EM ++ ++ +

Tooled up process + ++ ++ ++

Roles ++ + ++

Training + ++ ++ +

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 contributesto 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-shorestructures, 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 andnow as Practice Director in Thales University. She now covers the internal training (design and


15/15

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 SystemsEngineering 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 anddeployment 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.5GRCSE version 0.5 Release for Global Review December 2011

development of systems engineering people to support major transformation plans in thales

Documents