Determining Needed Systems Engineering Capabilities in Businesses and Enterprises
A key part of Enabling Businesses and Enterprises to Perform Systems Engineering is deciding on the desired systems engineering capabilities within the business and/or enterprise. First, the Organizational Purpose must be understood, then the value that systems engineering can provide is determined. Understanding the value that SE can provide within the organization in support of Organizational Purpose is the starting point for deciding the desired SE capabilities. This topic summarizes the issues that drive the decisions about desired SE capabilities for the business or enterprise. This has to take into account the factors that cause organizations to be different, so the topic also discusses the organizational design decisions and issues that may arise; and also how SE may interact with other functional areas in the organization, and what needs to be done to ensure that SE delivers maximum value to the organization.
Once the SE capabilities of the business and enterprise are determined, these capabilities are divided among organizations, teams and individuals. Determination of team SE capability is discussed in the topic Determining Needed Systems Engineering Capabilities in Teams, and the individual SE competencies are discussed in the topic Roles and Competencies.
The capability to perform systems engineering includes factors such as having competent personnel, adequate time, sufficient resources and equipment, and appropriate policies and procedures. The SE capability of a business or enterprise is dependent on all these factors. Social dynamics at the team and organizational levels also influence the SE capability realized.
Relationship of this topic to Enterprise Systems Engineering
Enterprise Systems Engineering techniques can be used to establish needed SE capabilities. Architecture modeling and analysis enables better understanding of the dependencies between capabilities of nodes in the enterprise. At a high level of abstraction, the following are basic steps that could be used to decide on the desired SE capabilities within the business and enterprise.
- Understand the context, including the factors shown in Table 1
- Determine the required SE roles
- Determine the competencies and capabilities needed for each of the SE roles
- Assess the ability and availability of the needed SE organizations, teams, and individuals
- Make adjustments to the required SE roles based on the actual ability and availability
- Organize the SE function in a manner that facilitates communication, coordination, and performance.
See the topic Organizing Business and Enterprises to Perform Systems Engineering for additional information. More information on context and required SE roles is provided below.
Contextual Drivers
The following discussion, and the summary table below, illustrates some of the contextual factors and drivers that influence the SE capability needed by a business or enterprise.
Where the SE activities are performed in the value chain:
This discussion uses the concepts set out in the "Organizational contexts for SE" section in Enabling Businesses and Enterprises to Perform Systems Engineering.
The systems engineering approach adopted by the business or enterprise should depend on whether the organization is:
- The problem owner – focus will be on identifying and scoping the system problem, understanding the nature of the appropriate respondent system, defining its interdependencies and interoperability with other current and envisaged systems, and establishing the capacity and capability to acquire, integrate and operate the relevant system assets to deliver the intended benefit (it may be appropriate for such organizations to use enterprise systems engineering and capability systems engineering approaches)
- System operator – focus will be on establishing all the necessary components of capability (glossary?) defined by: the DoD as DOTMLPF – doctrine, organization, training, materiel, logistics, people, facilities; by UK MOD as TEPIDOIL – training, equipment, people, information, doctrine, organization, infrastructure, logistics; with similar equivalent breakdowns either explicit or implicit in other domains and organization) to deliver the required services to the problem owner, and on integrating new system assets into the system operation as they become available (see for example Kemp & Linton, 2008, “Service Engineering”, INCOSE IS 2008 Utrecht; the Service Systems Engineering section of the SEBOK; Elliott (Bruce) et al, “systems engineering on in service systems”, INCOSE UK Chapter 20??; -- )
- Prime contractor – focus will be on understanding customer needs and trading alternative solution approaches, then establishing a system team and supply chain to develop, deliver, support and in some cases operate the system solution. Depending on the level of complexity and scale, this may require enterprise SE and capability SE as well as “traditional” SE (INCOSE SE Handbook, NASA SE handbook, CMMI DEV – author’s comment, I am not sure that the INCOSE SE Handbook pays enough attention to trade studies and TRLs, which are emphasised in the NASA SE Hdbk)
- Subsystem/component developer – focus will be on understanding the critical customer and system integrator issues for the subsystem or component of interest to the developed, establishing the component or subsystem boundary definition, and integrating critical technologies possibly in an innovative way to create a competitive solution. Often the business model at this level of the supply chain will favour solutions that exploit re-usable elements and can be sold in identical or modified form to several customers. (INCOSE SE Handbook, CMMI DEV, Reinertsen “developing products in half the time”, Pugh 1991 “total design”)
- Specialist service provider – focus will be on specific process capabilities and competences which are sold on a time and materials or work package basis to any of the other kinds of business or enterprise. (ref e.g. CMMI for service, the specific process areas in SEBOK and INCOSE SE Handbook)
Where the business or enterprise operates in the lifecycle
The core systems engineering competencies and capabilities developed by the business or enterprise will depend on which system lifecycle phase(s) (glossary?) it operates in:
- Concept phase – SE in the concept phase requires the capability to identify a “problem situation”, define context and potential conops for a solution system, assess feasibility and affordability of a range of solution options in broad terms, analyse needs, determine appropriate options to consider further, and refine the definition to allow development of system requirements for the solution.
- Development phase – SE in the development phase requires the capability (including staff competence, organisational capability and enabling infrastructure, etc) to
- engage with concept studies to ensure the business or enterprise addresses opportunities it is competent to respond to
- influence concept studies to ensure that specifications will be feasible and understood by the development organisation
- establish how much trade space remains at the end of the concept study to calibrate the scope for innovation and optimisation in the development program
- secure appropriate development work on appropriate terms
- perform the system development activities defined elsewhere in the SEBOK, including architecture design, detailed definition of the system elements and their interfaces, and integration, verification, qualification and validation
- produce definition data to allow the solution to be implemented, set to work, supported, operated and safely disposed of.
- Manufacturing phase – requires the capability to
- configure the manufacturing and logistics systems for the system assets,
- manufacture, test, certify, control the configuration of, and deliver system assets,
- to provide spares and repairs, manage obsolescence, - - as part of a logistic support service.
- In-service phase – requires the capability to
- maintain business continuity during the transition into operation of the new system,
- bring the system into service,
- integrate its capabilities into “business as usual”,
- manage and sustain all components of capability including people, process and logistic support
- maintain knowledge of the configuration (glossary?) of the deployed system(s)
- monitor system performance and effectiveness during operation,
- reconfigure the system to recover from performance drop-off and respond to emerging needs.
This requires the business or enterprise to be able to perform systems engineering at an operational tempo. See for example (Kemp & Linton, 2008) and (Bruce Elliott et al, ref to be confirmed, “In-Service Systems Engineering”)
- Retiral phase –requires the capability for ensuring the safe retirement of systems and keeping them in a state ready for re-activation (“mothballed”), or dismantling and recycling or safely disposing of the assets and their constituent parts.
Nature of responsibility to end users and society
Depending on the business model and the contracting environment, the business or enterprise may find that its responsibility to end users is
- Explicit: spelt out by clear requirements, prescriptive legislation
- Implicit: a legal or ethical obligation to ensure “fitness for purpose”, which may be enforced by commercial frameworks, national or international standards, and specific product liability legislation
Typically, businesses and enterprises whose business model is contract driven – for example the design-to-order of bespoke solutions - focus on satisfying explicit requirements, whereas market driven businesses and enterprises (including those offering “service products” such as air travel) have to take more account of implicit responsibilities.
Nature of responsibility to customers
The business or enterprise may contract with its customers to deliver any of the following:
- An Outcome: deliver the intended benefits the system is expected to provide
- An Output: deliver or operate the system or part of it against agreed acceptance criteria
- An Activity: perform specified processes
- A Resource: provide specified resource.
The systems engineering approach will have to be different in each case, in the first case requiring enterprise SE or capability systems engineering, in the second case Traditional Systems Engineering, in the third provision of a service, and in the last case focusing on individual competence of its staff.
Scale of systems
The business or enterprise may need very different systems engineering approaches depending on the scale of system at which the organization operates. The following categories are based on Hitchins’ 5 layered system model (Hitchins 2011 pp 113 - 123):
- Level 1: Subsystem and technical artefacts – focus will be on product systems engineering and on technology integration to achieve function and performance, and on managing the business or enterprise capability synergistically across multiple projects and product lines.
- Level 2: Project systems – focus will be on traditional systems engineering with cross-discipline and human integration to achieve system level function, performance and behaviour to deliver the required services in the appropriate operational environment
- Level 3: Business systems – focus will be on enterprise systems engineering to establish required business or enterprise capabilities, on capability systems engineering to define the required capabilities, on Service Systems Engineering to implement them, and on service management (ref SEI, CMMI for service) and continuous improvement (Lean, 6 sigma etc, refs to be worked out) for the day to day running of the business
- Level 4: Industry systems – if there is a conscious effort to treat a whole industry as a system, the focus will be on enterprise systems engineering, on flow through the co-operating and competing supply chains, and on the long-term economic and environmental sustainability of the overall industry.
- Level 5: Societal systems – enterprise systems engineering, system dynamics and systems thinking approaches are used to analyse and attempt to optimise societal systems; the clearest example of this to date is the Singapore System Model presented by PC Liu (INCOSE IS09, Singapore).
Sillitto and Godfrey (Sillitto 2011) have proposed extended this model properly to cover sustainability issues by adding two additional layers -“ecosystem” and “geosystem”.
Complexity of systems integration task - Stupples levels
(Elliot et al. 2007;) identify three “kinds” of systems engineering originally proposed by Stupples, to do with the level of cross-disciplinary integration involved:
- Within a discipline (e.g., software, electronics), the SE focus is on taking a systems view of the architecture and implementation to manage complexity and scale within a single engineering discipline;
- Multiple disciplines (e.g., software, hardware, optics, mechanical), the SE focus is on holistic integration of multiple technologies and skills to achieve a balanced system solution;
- Socio technical systems integration – the SE focus is on getting people and the non-human parts of the system working synergistically together – a less mature form of SE than the others, see e.g Sommerville at al (ref to be confirmed)
Sillitto and Godfrey have proposed extended this model properly to cover sustainability issues by adding one additional level – “Environmental Integration”. (Sillitto 2011) describes this and shows how the Stupples levels relate to other dimensions used to categorise systems and professional engineering skills.
Criticality of system and certification requirements
The level of rigour in the SE approach adopted by the business or enterprise will depend on criticality of various classes of requirement:
- Safety, Security often demand specific auditable processes and proof of staff competence
- Ethics, Environment, etc. May require audit of the whole supply and value chain
- Extremely demanding combinations of performance requirements will require more design iteration and more critical control of component characteristics (see for example Fasser & Brettner, management for quality in high-technology enterprises)
See HRO (High reliability Organization) discussion in another article in this part.
Nature of contract or agreement
The nature of the contractual relationship between business or enterprise and its customers and end users will influence the style of SE:
- Fixed price or cost plus or other – will determine whether the focus is on performance or on cost control and how the business or enterprise is incentivised to handle risk and opportunity.
- Mandated work share arrangements – the architecture of the optimum “product system” may be compromised or constrained by the architecture of a viable “business system”; this is often the case in multi-national projects and high profile government procurements (ref discussion elsewhere in SEBOK about Eurofighter Typhoon, the International Space Station (ref?), and Rechtin and Maier, “The art of systems architecting”, chapter on political influences).
- Self funded – the priorities will be requirements elicitation approaches designed to discover the latent needs of consumers and business customers, and development approaches designed to achieve rapid time to market with a competitive offering, and/or to have a competitive offering of sufficient maturity available at the critical time during a customer’s selection process.
- Single phase or whole-life – the business or enterprise may or may not be able to optimise trade-offs across the development, implementation and in-service budgets, and between the different components of capability (glossary).
Nature and predictability of problem domain
Well defined and slowly changing steady state permit use of traditional SE with waterfall lifecycle models, because requirements risk and change is expected to be low.
Poorly defined and rapidly changing problem domains, with operators subject to unpredictable and evolving threats (e.g. defense), demand more flexible solutions and agile processes - SE should focus on modular architectures that allow rapid reconfiguration of systems and systems-of-systems, and rapid deployment of new technologies at subsystem level, to meet new demands and threats.
Fundamental risks and design drivers in solution domain
When the solution domain is stable, with a low rate of technology evolution, and systems use mature technology, the focus is on optimum packaging and configuration of known and usually well-proven building blocks within known reference architectures, and on low-risk incremental improvement over time.
When there is rapid technology evolution, with pressure to bring new technologies rapidly to market/ into operational use, the SE approach has to focus on technology maturation, proof of technology and integration readiness, and handling the technology risk in the transition from lab to proof of concept to operational system.
There is usually a trade-off between Lead time expectations versus level of integrity/certification: in the development of new systems, short lead times are seldom compatible with high levels of system integrity and rigorous certification.
Competitive situation and business goals
The business drivers for systems engineering deployment may be:
- Do existing business better
- Recover from a competitive shock or a shift in clients' expectations
- Develop a new generation product or service
- Enter a new market
- Reposition the business or enterprise in the value chain
In the first case SE can be deployed incrementally in parts of the business process where early tangible benefits can be realised. Preferably this should be in the context of a wider improvement plan across the business, and be the early steps of a strategic plan for systems engineering – CMMI may provide a good structure for such a plan.
In the other cases the business is going through disruptive change and the early priority will be to use systems thinking and enterprise systems engineering approaches to scope the change, and the plan needs to be driven strategically as a major change initiative to have a good chance of success.
Type of system or service
Referring to (other section) there are three distinct flavours of product or service type:
- Product or productized service – the focus will be on: predicting how the market might change during the development period; eliciting, anticipating and balancing requirements from a variety of potential customers; and optimising features and product attractiveness against cost and reliability.
- Custom solution (product or service) – the focus will be on feasible and (usually) low-risk approaches to meet the stated requirement within budget using system elements and technologies that are known or expected to be available within the desired development timescale.
- Tailored solution based on standard product and/or service elements – this requires a much more sophisticated SE process that is able to use a “product line approach”, to blend standard modules with bespoke adaptation to meet clients’ specific needs more quickly and cheaply than would be possible with a bespoke solution. The enterprise needs to manage the lifecycle and configuration of the standard modules separately from but coherently with the lifecycle and configuration of each tailored solution.
Summary Table
The table below summarises the discussion above.
| Environmental Factor | Examples |
|---|---|
| Where the SE activities are performed in the value chain:
See the discussion on "Organizational contexts for SE" in Enabling Businesses and Enterprises to Perform Systems Engineering. |
Whether the organization is:
|
| Where the business or enterprise operates in the lifecycle |
|
| Nature of responsibility to end users |
|
| Nature of responsibility to customers |
|
| Scale of systems | Hitchins level (Hitchins 1995; Hitchins 2005) at which the organization operates:
|
| Complexity of systems integration task - Stupples levels,
(Elliot et al. 2007; Sillitto 2011) |
|
| Criticality of system and certification requirements |
|
| Nature of contract |
|
| Nature and predictability of problem domain |
|
| Fundamental risks and design drivers in solution domain |
|
| Competitive situation and business goals |
|
| Type of system or service |
|
Required SE Roles
Enterprise Systems Engineering techniques can be used to establish needed SE capabilities from first principles. This implies the need for an enterprise systems engineering team, either permanent or ad hoc, that has both the necessary enterprise SE skills and the necessary influence with senior decision makers in the organization.
After understanding the context for the business and/or enterprise, the next step is to determine the required SE capabilities. The SEI Capability Maturity Models for Acquisition, Development and Services (SEI 2010) provide a framework for selecting systems engineering capabilities relevant to different types of business and enterprise.
The SE roles and competencies the organization needs to develop depend on the capabilities it needs to do its business, and on the type of organizational model selected for the business or enterprise. Existing SE competency models can be used to assist in determining the needed capabilities. An example is the INCOSE SE Competencies Framework (INCOSE 2010b). See the Roles and Competencies topic for more information on competency models.
As shown in Figure 1 below, management action on workforce development will be required if there are systemic mismatches between the competencies required to perform systems engineering roles and the actual competencies of individuals. Organizational culture may have a positive or negative effect on team performance and overall value added by the business or enterprise.
Need for Clarity of SE Approach, and Dangers in Implementing SE
In any organization where activities and skills are shared, there is always a danger of silos or duplication. One of the purposes of SE is to reduce this risk – consider the interface or glue role (Sheard 1996), or the idea that “SE is good engineering with special areas of emphasis, … including interfaces between disciplines” (Blanchard and Fabrycky 2005).
Clarity on how the organization does SE is important. Typically, implementing SE may be part of an organization improvement, so Kotter’s principles on creating a vision, communicating the vision and empowering the others to act on the vision are most relevant (Kotter 1995). The way an organization chooses to do systems engineering should be part of the vision of the organization – and must be understood and accepted by all.
Many of the major obstacles in systems engineering deployment are cultural (see Culture).
Systems engineering can make a very powerful contribution to the organization’s quality goals. Embedding SE principles, processes and methods in the organization’s quality management system means that senior management and the quality system will help embed SE in the organizational business process and make sure it is applied (INCOSE 2011; ISO 2008).
One of the lean enablers for SE (Oppenheim et al. 2010) is "pursue perfection". The means of improvement at business or enterprise level is discussed in detail elsewhere, but the starting point has to be deciding the SE capabilities the organization wants.
A business or enterprise is a system – and SE is one of the functions that system may need to perform. The specific requirements for the SE function can be derived from understanding what the overall system (the organization) needs to do, and from the relationship between SE and other functions within the organization at different levels. Ideally, there would be a tailored solution to an organization's SE requirements based on the unique set of purpose, scope, context, capability, and culture of each organization. Also, organizations change over time (learning, improving or losing capability) and so the balancing of SE with everything else keeps changing.
Balancing the need for a systematic and standardized approach to SE processes, such as defined in models and handbooks, with the flexibility inherent in systemic thinking is critical. Systems thinking helps the organization understand problem situations, remove organizational barriers and blockers, and make the most of the organizations technical capabilities (see (Beasley 2011), for example).
References
Citations
Beasley, R. 2011. "The Three T's of Systems Engineering." Paper presented at the 21st Annual International Council on Systems Engineering (INCOSE) International Symposium. June 2011. Denver, CO, USA.
Blanchard, B. and W. Fabrycky. 2005. Systems Engineering and Analysis, 4th edition. Upper Saddle River, NJ, USA: Prentice Hall.
Hitchins, D. 1995. "World Class Systems Engineering in The UK. Paper presented at the 1995 Euroforum Conference on Managing Systems Engineering for Competitive Advantage, 28-29 June 1995. London, UK.
Elliott, C. et al. 2007. Creating Systems That Work – Principles of Engineering Systems for The 21st century. London, UK: Royal Academy of Engineering. Accessed on September 14, 2011. Available at http://www.raeng.org.uk/education/vps/pdf/RAE_Systems_Report.pdf.
Hitchins, D. 2005. Systems Engineering 5 Layer Model. Accessed on September 14, 2011. Available at http://www.hitchins.net/5layer.html.
INCOSE. 2010. SE Competencies Framework, Issue 3. Somerset, UK: International Council on Systems Engineering (INCOSE), INCOSE Technical Product 2010-0205.
INCOSE. 2011. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
ISO/IEC 2008. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.
Kotter, J. 1995. Leading Change: Why Transformation Efforts Fail. Boston, MA, USA: Harvard Business Review (March–April 1995).
Oppenheim et al. 2010. Lean Enablers for Systems Engineering. Hoboken, NJ, USA: Wiley Periodicals. Accessed September 2, 2011. Available at http://cse.lmu.edu/Assets/Lean+Enablers.pdf.
SEI. 2010. Capability Maturity Model Integrated (CMMI) for Development, version 1.3. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).
Sheard, S. 1996. "12 Systems Engineering Roles." Paper presented at the 6th Annual International Council on Systems Engineering (INCOSE) International Symposium. Boston, MA, USA. Accessed September 14, 2011. Available at: http://www.incose.org/educationcareers/PDF/12-roles.pdf.
Sillitto, H. 2011. "Unravelling Systems Engineers from Systems Engineering - Frameworks for Understanding the Extent, Variety and Ambiguity of Systems Engineering and Systems Engineers." Paper presented at the 21st Annual International Council on Systems Engineering (INCOSE) International Symposium. 20-23 June 2011. Denver, CO, USA.
Primary References
Hitchins, D K, 2007: "Systems Engineering - a 21st Century Systems Methodology", Wiley 2007 Oppenheim, B, 2011: "Lean for Systems Engineering - with Lean Enablers for Systems Engineering", Wiley 2011
Additional References
Rhodes, D. and G. Roedler (eds.). 2007. Systems Engineering Leading Indicators Guide, version 1.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-02. Accessed September 14, 2011. Available at http://www.afit.edu/cse/docs/pubs/SELeadingIndicators2007-0618.pdf.