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 (called "business" as a shorthand because a business is a specific type of enterprise that has sufficiently strong central authority and motivation to take steps to enable SE). The SE capabilities required need to be defined based on the value SE can provide in support of the Organizational Purpose and business strategy. This topic summarizes the factors to take into account to determine the desired SE capabilities for a business. This includes the interactions between SE and other functional areas in the business, and consideration of social dynamics and leadership at the team and business levels.
Once the desired SE capabilities of the business are determined, these capabilities are divided allocated to the teams and individuals in the business. Determination of team SE capability is discussed in Determining Needed Systems Engineering Capabilities in Teams, and the individual SE competencies are discussed in Roles and Competencies.
The capability to perform SE needs to include defining SE roles and filling them, adequate time to perform SE (see Planning), methods / tools, and process.
Relationship of this Topic to Enterprise Systems Engineering
Enterprise Systems Engineering and Capability Engineering techniques can be used to establish needed SE capabilities. At a high level of abstraction, the following are basic steps that could be used to decide the desired SE capabilities within the business:
- understand the context;
- 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 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 illustrates some of the contextual factors that influence the definition of the SE capability needed by a business.
Where the SE Activities are Performed in the Value Chain
The SE approach adopted by the business should depend on what role the organization plays. Ring (2002) defines a value cycle, and where the business sits in that cycle is a key influence of SE cpaability need.
- problem owner: the focus will be on identifying and scoping the system problem (defining system of interest (glossary, and understanding the nature of the appropriate respondent system. 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 Service Systems Engineering). 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 for more information and references to the literature).
- 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, establish the component or subsystem boundary definition, and integrate 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 forms to several customers (in Part 4 of the SEBoK, see Systems of Systems, Enterprise Systems Engineering, and Product Systems Engineering for more information and references to the literature).
- 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.
Where the Enterprise Operates in the Lifecycle
The core SE competencies and capabilities developed by the enterprise will depend on the system life cycle phase(s) in which it operates.
- In the concept phase, SE requires the capability to identify a “problem situation,” define the context and potential concept of operations for a solution system, assess the feasibility and affordability of a range of possible solutions 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 addresses opportunities in which it is competent;
- influence concept studies to ensure that the 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 logistical 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 business to be able to perform SE at an appropriate operational tempo, which varies with how the enterprise delivers value.
- 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 business 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, businesses whose business model is contract driven; i.e., the design-to-order for contracted solutions, focus on satisfying explicit requirements, whereas market-driven businesses, 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 enterprise may contract with its customers to deliver any of the following:
- an outcome; i.e., 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 set of tasks; 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. The second case requires product SE. The third case requires service SE 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 2005).
- 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 product 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 enterprise capabilities, on service SE to implement them, and on service management (Chang 2010) and continuous improvement (SEI 2010b; see also Quality Management) 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 is used to analyze and attempt to optimize societal systems (see Singapore Water Management Vignette in Part 7 of the SEBoK).
Sillitto and Godfrey have proposed extending this model to cover sustainability issues by adding two additional layers, the “ecosystem” and the “geosystem” (Sillitto 2011).
Complexity of Systems Integration Tasks and Stupples’ levels
Creating Systems That Work – Principles of Engineering Systems for The 21st century identifies three “kinds” of SE, originally proposed by Stupples, that have to do with the level of cross-disciplinary integration involved (Elliot et al. 2007).
- Within a discipline (e.g., software, hardware, optics, or mechanics), 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. (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 will depend on the criticality of various classes of requirement (see Systems Engineering and Specialty Engineering).
- Safety and security requirements often demand specific auditable processes and proof of staff competence.
- Ethical and environmental requirements 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; e.g., see Quality Management and Management for Quality in High-Technology Enterprises (Fasser and Brettner 2010).
The Nature of a Contract or Agreement
The nature of the contractual relationship between an enterprise and its customers and end users will influence the style of SE.
- Fixed price, cost plus, or other contracting models influence the mix of focus on performance and cost control and how the enterprise is incentivized to handle risk and opportunity.
- In mandated work share arrangements, the architecture of the 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 (Maier and Rechtin 2009, 361-373).
- 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, or to have a competitive offering of sufficient maturity available at the most critical time during a customer’s selection process.
- In single phase, or whole-life approaches, the enterprise may be able to optimize trade-offs across the development, implementation, and in-service budgets, and between the different components of capability .
The Nature and Predictability of Problem Domain(s)
Well-defined and slowly-changing technologies, products, and services permit the use of traditional SE life cycle models based on the waterfall model because the requirements risk and change is expected to be low (see Life Cycle Models).
Poorly defined and rapidly changing problem domains, with operators subject to unpredictable and evolving threats, 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:
- to perform existing business better;
- to recover from a competitive shock or a shift in clients' expectations;
- to develop a new generation product or service;
- to enter a new market; and/or
- to 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 SE (see article about improving capability - REF).
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
There are three distinct flavors of products or service types (see Organizational Purpose):
- 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 planned adaptation to meet clients’ specific needs more quickly and cheaply than would be possible with a single contract solution. The business needs to manage the life cycle and configuration of the standard modules separately from, but coherently with, the life cycle 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 | Whether the organization is:
|
| Where the business or enterprise operates in the life cycle |
|
| Nature of responsibility to end users |
|
| Nature of responsibility to customers |
|
| Scale of systems at which the organization operates |
|
| Complexity of systems integration task – Stupples’ levels |
|
| 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 a business 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, the next step is to determine the required SE capabilities. The SEI Capability Maturity Models for acquisition, development, and services (SEI 2007; SEI 2010a; SEI 2010b) provide a framework for selecting SE capabilities relevant to different types of business.
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. 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 Roles and Competencies 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. The organizational culture may have a positive or negative effect on team performance and the overall value added by the business (see Culture).
Need for Clarity in the 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; for example, 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 extremely 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; see Quality Management).
One of the lean enablers for SE is to "pursue perfection" (Oppenheim et al. 2010). The means of improvement at a business or enterprise level are discussed in detail elsewhere, but the starting point has to be deciding what SE capabilities the organization wants.
A business 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 "The Three T's of Systems Engineering" (Beasley 2011)).
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 business strategy and be developed in cooperation and collaboration with members of the entire business 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.
Chang, C.M. 2010. Service Systems Management and Engineering: Creating Strategic Differentiation and Operational Excellence. Hoboken, NJ, USA: John Wiley and Sons.
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.
Fasser, Y. and D. Brettner. 2001. Management for Quality in High-Technology Enterprises. New York, NY, USA: Wiley.
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.
Hitchins, D. 2005. Systems Engineering 5 Layer Model. Accessed on September 14, 2011. Available at http://www.hitchins.net/5layer.html.
Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Chichester, UK: Wiley and Sons, Inc.
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).
Maier, M. and E. Rechtin. 2009. The Art of System Architecting, Third Edition. Boca Raton, FL, USA: CRC Press.
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.
Ring J. 2002. Toward an ontology of Systems Engineering INSIGHT, 5(1): 19-22
SEI. 2007. CMMI for Acquisition. Version 1.2. Technical Report CMU/SEI-2007-TR-017. Pittsburgh, PA, USA: Software Engineering Institute, Carnegie Mellon University.
SEI. 2010a. Capability Maturity Model Integrated (CMMI) for Development. Version 1.3. Pittsburgh, PA, USA: Software Engineering Institute, Carnegie Mellon University.
SEI. 2010b. CMMI for Services. Version 1.3. Technical Report CMU/SEI-2010-TR-034. Pittsburgh, PA, USA: Software Engineering Institute, Carnegie Mellon University.
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. 2007. Systems Engineering: A 21st Century Systems Methodology. Chichester, UK: Wiley and Sons, Inc.
Oppenheim, B. 2011. Lean for Systems Engineering - with Lean Enablers for Systems Engineering. Hoboken, NJ: Wiley and Sons, Inc.
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.
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.
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus