Determining Needed Systems Engineering Capabilities in Businesses and Enterprises

From SEBoK
Jump to navigation Jump to search

To enable a business or enterprise to perform systems engineering (SE) well requires deciding which specific SE capabilities the business or enterprise needs in order to be successful. (In the rest of this article, business or enterprise is usually abbreviated to just "business" because a business is a specific type of enterprise that has sufficiently strong central authority and motivation to take steps to enable SE). SE capabilities should support the Systems Engineering Organizational Strategy and reflect the nature of the business, its products and services, various stakeholders, business leadership focus, etc. This topic, which is part of Part 5: Enabling Businesses and Enterprises, summarizes the factors used to decide which SE capabilities a business needs; e.g., the interactions between SE and other functional areas in the business, and consideration of social dynamics and leadership at the team and business levels. Needed capabilities may be decided and developed centrally by a business, or within teams and individuals, or through some combination of the two. Determination of team SE capability is discussed in Determining Needed Systems Engineering Capabilities in Teams, and individual SE competencies are discussed in Roles and Competencies.

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:

  1. understand the context;
  2. determine the required SE roles;
  3. determine the competencies and capabilities needed for each of the SE roles;
  4. assess the ability and availability of the needed SE organizations, teams, and individuals;
  5. make adjustments to the required SE roles based on the actual ability and availability; and
  6. 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 capability need.

  • System operator: focus on establishing all the necessary components of capability to deliver the required services, 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 - e.g.
    • 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.
  • Prime contractor or primary commercial developer: 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. This may require enterprise SE (see Enterprise Systems Engineering) as well as "traditional" product SE (see Product Systems Engineering).
  • Subsystem/component developer: focus on understanding the critical customer and system integrator issues for the subsystem or component of interest, define the component or subsystem boundary, and integrate critical technologies. This may 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).
  • Specialist service provider: focus on specific process capabilities and competences which are typically sold on a time and materials or work package basis to other businesses.

Where the Enterprise Operates in the Lifecycle

The SE capabilities required by the business will depend on the system life cycle phase(s) in which it operates (see Life Cycle Models in Part 3).

  • Concept definition phase: requires the SE capability to identify a “problem situation,” define the context and potential concept of operations for a solution system, assess the feasibility of a range of possible solutions in broad terms, and refine the definition to allow the development of system requirements for the solution (see Concept Definition in part 3).
  • System Definition phase: requires the SE capability to influence concept studies (ensure feasible and understood by the development team), establish the trade space that remains at the end of the concept study, perform the system definition activities, including architecture design, detailed definition of the system elements.
  • System realization phase: requires the SE capability to configure the manufacturing and logistics systems for the system assets, and manufacture system assets - see System Realization.
  • System deployment and use: requires the SE capability to maintain business continuity during the transition to operation, bring the system into service, support system, monitor system performance, and respond to emerging needs (see System Deployment and Use. (Elliott et al. 2008) describe the different emphases that should be placed in SE during the "in-service" phase. This phase particularly requires the business to be able to perform SE at an appropriate operational tempo.
  • Retirement phase: requires the SE capability for ensuring the safe retirement of systems and keeping them in a state ready for re-activation (“mothballed”), safe disposal of the system assets.

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 focus on satisfying explicit requirements, whereas market-driven businesses have to be more aware of implicit responsibilities.

Nature of Responsibility to Customers

The business may contract with its customers to deliver any of the following:

Scale of Systems

The business or enterprise may need very different SE approaches depending on the scale of the system at which the business operates. The following categories are based on Hitchins’ five layered system model (Hitchins 2005).

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 (Stupples, 2006), 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 (2011) proposed extending this model properly to cover sustainability issues by adding one additional level, “Environmental Integration”. He describes 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 Systems Engineering Organizational Strategy):

  • 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.

Required SE Roles

After understanding the context for the business, the next step is to determine the SE capabilities required in the role in the business. 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. 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.).

There can be a wide spectrum of the spread of SE focus - from SE being focused in a specialist role, an 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) and so it is shared by all. In any organization where activities and skills are shared, there is always a danger of silos or duplication.

As part of the role definition the business must define where an individual doing SE fits into career progression (what roles before SE, what after?). Developing Individuals describes how individuals improve Se; the organisation must definethe means by which that development can be enacted. Businesses need to customise from a range of development strategies, see for example (Davidz and Martin, 2011).

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).

Figure 1. Culture, Competence, Team Performance and Individual Competence (Figure Developed for BKCASE)

Required SE Processes and methods

The decisions on how to implement SE capability must be embedded in the businesses processes and its availablilty methodologies and toolsets. 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).

When defining the processes and tools a balance between the need for a systematic and standardized approach to SE processes, such as (INCOSE, 2011) 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)).

Need for Clarity in the SE Approach and the Dangers of Implementing SE

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).

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. It needs to be recognized that change over time (learning, improving, or losing capability). Thus, balancing SE with everything else that it involves is an ever changing process.

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.

Davidz, H. L. and J. Martin. 2011. "Defining a Strategy for Development of Systems Capability in the Workforce." Systems Engineering. 14(2) (Summer, 2011): 141-143

Elliott, B. et al. 2008. INCOSE UK Chapter Working Group on Applying Systems Engineering to In-Service Systems, Final Report. Somerset, UK: INCOSE UK Chapter Working Group. Accessed September 6, 2011. Available at http://www.incoseonline.org.uk/Documents/Groups/InServiceSystems/is_tr_001_final_report_final_1_0.pdf.

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.

Stupples, D. 2006. "Systems Engineering – a road from perdition." Published on Royal Academy of Engineering webiste - available at http://www.raeng.org.uk/education/vps/systemdesign/pdf/David_Stupples.pdf

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. Twelve 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.

< Previous Article | Parent Article | Next Article >


SEBoK v. 1.9.1 released 30 September 2018

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

Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Determining_Needed_Systems_Engineering_Capabilities_in_Businesses_and_Enterprises&oldid=39085"