Determining Needed Systems Engineering Capabilities in Businesses and Enterprises
Enabling Businesses and Enterprises to Perform Systems Engineering includes deciding on the desired systems engineering (SE) capabilities within the business or enterprise (hereafter, this article just uses the term "enterprise" because a business is a special form of enterprise). Ideally, a decision on desired capabilities is made in the context of the Organizational Purpose must be understood, and then the value that SE can provide is determined. Required SE capabilities flow down from the enterprise strategy; understanding the value that SE can provide within the organization in support of Organizational Purpose and enterprise strategy 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 enterprise. Because SE has to take into account the factors that differentiate organizations, this topic also discusses the organizational design decisions and issues that may arise, as well as how SE may interact with other functional areas in the organization, and what needs to be done to ensure that SE delivers high value to an organization.
Once the SE capabilities of the 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 SE includes factors such as having competent personnel, adequate time, sufficient resources, tools, and equipment, and appropriate policies and procedures. The SE capability of an enterprise is dependent on all these factors. Social dynamics at the team and organizational levels also influence the realization of SE capability.
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 components of the enterprise. At a high level of abstraction, the following are basic steps that could be used to decide the desired SE capabilities within the 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; and
- organize the SE function to facilitate 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 an 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 to Enable businesses and enterprises to perform SE.
The SE approach adopted by the enterprise should depend on what role the organization plays.
- If the organization is the problem owner, the 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 SE and capability SE approaches.
- If the organization is the system operator, the focus will be on establishing all the necessary components of capability to deliver the required services to the problem owner, as well as 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”; and INCOSE UK Chapter 20??; -- ) The definition of the components of capability varies by organization.
- The US Department of Defense defines the components of capability as DOTMLPF, i.e., doctrine, organization, training, materiel, logistics, people, and facilities.
- The UK Ministry of Defense defines the components of capability as TEPIDOIL, i.e., training, equipment, people, information, doctrine, organization, infrastructure, and logistics.
- Other domains and organizations define the components of capability with similar, equivalent breakdowns which are either explicit or implicit.
- If the organization is a prime contractor, it will focus 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 (see Enterprise Systems Engineering) as well as "traditional" product SE (see Product Systems Engineering) (INCOSE SE Handbook; NASA SE handbook; CMMI DEV).
- If the organization is a subsystem/component developer, it will focus 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 favor 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”).
- If the organization is a specialist service provider, it will focus on specific process capabilities and competences which are sold on a time and materials or work package basis to other enterprises (e.g., CMMI for service and the specific process areas in SEBoK and the INCOSE SE Handbook).
Where the Enterprise Operates in the Lifecycle
The core SE competencies and capabilities developed by the enterprise will depend on which system life cycle phase(s) in which it operates.
- In the concept phase, SE requires the capability to identify a “problem situation”, define context and potential concept of operations for a solution system, assess the feasibility and affordability of a range of solution options in broad terms, analyze needs, determine appropriate options for further consideration , and refine the definition to allow the development of system requirements for the solution.
- In the development phase, SE requires the capability (including staff competence, organizational capability, enabling infrastructure, etc.) to perform the following:
- engage with concept studies to ensure the business or enterprise addresses opportunities in which it is competent;
- influence concept studies to ensure that specifications will be feasible and understood by the development organization;
- establish the amount of trade space that remains at the end of the concept study to calibrate the scope for innovation and optimization in the development program;
- secure appropriate development work on appropriate terms;
- perform the system development activities defined in Part 3 of the SEBoK, Systems Engineering and Management, including architecture design, detailed definition of the system elements and their interfaces, integration, verification, qualification, and validation; and
- produce definition data to allow the solution to be implemented, set to work, supported, operated, and safely disposed of.
- The manufacturing phase requires the capability to perform the following:
- configure the manufacturing and logistics systems for the system assets;
- manufacture, test, certify, control the configuration of, and deliver system assets; and
- provide spares, repairs, and manage obsolescence as part of a logistic support service.
- The in-service phase requires the capability to perform the following:
- maintain business continuity during the transition into the 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, processes, and logistic support;
- maintain knowledge of the configuration of the deployed system(s);
- monitor system performance and effectiveness during operation; and
- reconfigure the system to recover from performance drop-off and respond to emerging needs.
This requires the enterprise to be able to perform SE at an appropriate operational tempo, which varies with how the enterprise delivers value. See for example (Kemp & Linton 2008) and (Bruce Elliott et al. ref to be confirmed, “In-Service Systems Engineering”)
- The retirement phase requires the capability for ensuring the safe retirement of systems and keeping them in a state ready for re-activation (“mothballed”), dismantling and recycling, or safe disposal 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 enterprise may find that its responsibility to end users is:
- explicit or spelled out by clear requirements and prescriptive legislation; or
- implicit; i.e., 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, enterprises whose business model is contract driven; i.e., the design-to-order for contracted solutions, focus on satisfying explicit requirements, whereas market-driven enterprises, including those offering “service products” such as air travel or package delivery, have to be more aware 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, i.e., deliver the intended benefits the system is expected to provide;
- an Output, i.e., deliver or operate the system or part of it against agreed acceptance criteria;
- an Activity, i.e., perform a specified processes; and
- a resource, i.e., provide a specified resource.
The SE approach will have to be different in each case. The first case requires enterprise SE or capability SE. The second case requires traditional SE. The third case requires the provision of a service and the last case requires focus on the individual competence of its staff.
Scale of Systems
The business or enterprise may need very different SE approaches depending on the scale of the system at which the organization operates. The following categories are based on Hitchins’ five layered system model (Hitchins 2011, pp 113 - 123).
- Level 1: Subsystem and technical artifacts – The focus will be on product SE 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 – The focus will be on traditional SE with cross-discipline and human integration to achieve system level function, performance, and behavior to deliver the required services in the appropriate operational environment.
- Level 3: Business systems – The focus will be on enterprise SE to establish required business or enterprise capabilities, on capability SE to define the required capabilities, on service SE to implement them, and on service management (SEI and 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 an entire industry as a system, the focus will be on enterprise SE, on flow through for 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 SE, system dynamics, and systems thinking approaches are used to analyze and attempt to optimize 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 extending this model properly to cover sustainability issues by adding two additional layers, the “ecosystem” and the “geosystem”.
Complexity of Systems Integration Task and Stupples’ levels
(Elliot et al. 2007) identify three “kinds” of SE, originally proposed by Stupples, that have to do with the level of cross-disciplinary integration involved.
- Within a discipline (e.g., software or 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.
- In multiple disciplines (e.g., software, hardware, optics, and mechanical), the SE focus is on holistic integration of multiple technologies and skills to achieve a balanced system solution.
- In 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. (For an example see Sommerville et al. (ref to be confirmed).
Sillitto and Godfrey have proposed extending this model properly to cover sustainability issues by adding one additional level, “Environmental Integration” (Sillitto 2011). They describe this level and show how the Stupples’ levels relate to other dimensions used to categorize systems and professional engineering skills.
Criticality of System and Certification Requirements
The level of rigor in the SE approach adopted by the business or enterprise will depend on the criticality of various classes of requirement.
- Safety and security often demand specific auditable processes and proof of staff competence.
- Ethics, Environment, etc. may require an 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 (for an example, see Fasser and Brettner, “Management for Quality in High-Technology Enterprises”).
See the High reliability Organization (HRO) 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, cost plus, or other will determine whether the focus is on performance or on cost control and how the business or enterprise is incentivized to handle risk and opportunity.
- In 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).
- In self-funded approaches, 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.
- In single phase or whole-life approaches, the business or enterprise may or may not be able to optimize trade-offs across the development, implementation and in-service budgets, and between the different components of capability (glossary).
Nature and Predictability of Problem Domain(s)
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, as well as rapid deployment of new technologies at a subsystem level to meet new demands and threats.
Fundamental Risks and Design Drivers in the 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 and/or 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 the lab to the proof of concept to the operational system.
There is usually a trade-off between lead time expectations and the 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 SE deployment may be one or more of the following:
- perform 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; and/or
- 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 realized. 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 SE approaches to scope the change. 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 flavors of product or service type:
- In a 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 optimizing features and product attractiveness against cost and reliability.
- In a custom solution (product or service) the focus will be on feasible and low-risk (usually) 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 solutions based on standard product and/or service elements require 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 summarizes 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 SE 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 SE 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 SE roles and the actual competencies of individuals. Organizational culture may have a positive or negative effect on team performance and the overall value added by the business or enterprise.
Need for Clarity of SE Approach and the Dangers of 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’s improvement, so Kotter’s principles on creating a vision, communicating the vision, and empowering others to act on the vision, are most relevant (Kotter 1995). The way an organization chooses to do SE should be part of the vision of the organization and must be understood and accepted by all.
Many of the major obstacles in SE deployment are cultural (see Culture).
SE 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 to "pursue perfection." The means of improvement at a business or enterprise level is discussed in detail elsewhere, but the starting point has to be deciding what SE capabilities the organization wants.
A business or enterprise is a system and SE is one of the functions that the 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 purposes, scope, context, capabilities, and the culture of each organization. Also, organizations change over time (learning, improving, or losing capability). Thus, balancing SE with everything else that it involves is an ever changing process.
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 organization’s technical capabilities (see (Beasley 2011), for example).
Finally, a key ingredient in deciding what SE Capabilities are required is listening to other stakeholders (e.g., program managers and corporate/enterprise leaders) and enlisting their feedback. In fact, the entire SE strategy should flow down from the enterprise strategy and be developed in cooperation and collaboration with members of the entire enterprise leadership team (other engineering disciplines, HR, Finance, Supply Chain, Training, etc.).
References
Works Cited
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.