Premium
5.4.1 Would the real systems engineer please stand up?
Author(s) -
Kemp Duncan,
Mollett Jennifer
Publication year - 2011
Publication title -
incose international symposium
Language(s) - English
Resource type - Journals
ISSN - 2334-5837
DOI - 10.1002/j.2334-5837.2011.tb01229.x
Subject(s) - process (computing) , engineering management , service (business) , engineering , product (mathematics) , system of systems engineering , engineering design process , product service system , government (linguistics) , information system , systems engineering , computer science , process management , systems design , business , business model , mechanical engineering , linguistics , philosophy , geometry , mathematics , electrical engineering , marketing , operating system
Abstract The conventional systems engineering process (as defined in ISO 15288 or the INCOSE SE handbook) assumes that projects start with a defined requirement or problem statement and end with contract acceptance or in‐service validation. This has led to a belief by some in industry that the role of systems engineers within client organisations is kicking‐off and accepting well formed programmes for industry to deliver. Whilst this is an important role, it is not the only part of the client side systems engineer's job. This paper describes the activities that systems engineers do when working for the client such as government, a transport service company or an information services company. Far from just playing a peripheral role in product systems engineering, the client side systems engineer is involved in:Capability systems engineering ‐ identifying, developing and integrating systems and services to realise operational capability Service systems engineering – integrating existing and newly delivered systems to deliver operational services Enterprise systems engineering – redesigning their organisations to improve organisational performance or reduce costs This paper describes these different systems engineering disciplines and draws comparisons between the types of systems engineering needed to deliver capabilities, services and enterprises and the more familiar approaches needed to deliver products (included at Annex A). The paper examines the different tools, processes, people and relationships needed to undertake these different types of systems engineering, in particular comparing them to conventional product systems engineering. Additionally, the paper introduces a framework within which the different types of systems engineering can be evaluated.