Development of Systems Engineering People To Support Major Transformation Plans in Thales
Development of Systems Engineering People To Support Major Transformation Plans in Thales
Development of Systems Engineering People To Support Major Transformation Plans in Thales
Thales Universit
odile.mornas@thalesgroup.com
Thales Universit
catherine.laporte@thalesgroup.com
Roland Mazzella
Anne Sigogne
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.
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
Manage
Competences
Continuous
Improvement
Define the
strategy
(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
Launch R
Gate 3
Gate 2
CCR
BBR
Gate 1
Contract
Entr y into Force
End Production
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
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
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.
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
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.
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
CC
CC Manager
Manager
(Competence
(Competence
Centre)
Centre)
Technical
Technical
Director
Director
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)
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
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
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),
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,
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)
++
Sys-EM
Tooled up process
Roles
Training
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
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